With this code:
Dim sf As New StackFrame(0, True)
MessageBox.Show("Module: " & sf.GetFileName & " -Line: " & sf.GetFileLineNumber.ToString)
I can get Class and Line number where an Unhandled Exception occurred (in ApplicationEvents.vb, Sub MyApplication_UnhandledException(...) Handles Me.UnhandledException)
But if I obfuscate the code using EazFuscator (and maybe with any others) I lose the data: I get a NullString and 0 for line number.
Inserting the code:
<Assembly: Obfuscation(Feature:="encrypt symbol names with password XXXX", Exclude:=False)>
nothing changes. I can decompile the e.message, but the lines are lost. How can I get the line for an error in obfuscated code?
No it is not possible, and this is intended. Unhandled exceptions are a source of information for a potential attacker. Normally you should only ever apply obfuscation on a production build, after the first round of tests have passed. Don't try to debug an obfuscated assembly, it's obfuscated specifically to prevent debugging, among other things.
I should add that the real reason why you cannot get the information is that the debug symbols have been stripped from the assembly by the obfuscation process. That information should be shown as long as you have a valid PDB file for your assembly.
You can get the line numbers in your stack traces. They are stored in .pdb files. By default, Eazfuscator.NET sanitizes .pdb files by making them essentially empty. That's why you don't see the line numbers for obfuscated assemblies.
But you can instruct Eazfuscator.NET to process .pdb files so that the line numbers are preserved:
<Assembly: Obfuscation(Feature:="debug [relative_file_paths secure]", Exclude:=False)>
Once the directive is in place, you will see the lines in stack traces of an obfuscated assembly. Thanks to secure flag, the .pdb file remains encrypted and thus does not pose a security risk.
Related
I have a client who has asked me to fix a problem with a corrupt user.config file. The config file has enough of an XLM header for the program to load the settings, but the rest of the config file is nulls (0x00) so the config loads, but then an error occurs when attempting to access any of its member. Note: the 0x00 value pops up in the error message later.
After much research, the common suggested solution seems to be delete the user.config file and then do a My.Settings.Reset but this doesn't work for me. The only solution that seems to work is to delete the user.config file, and then shut down and restart the program. The program starts and runs fine after deleting the user.config file. It creates a new user.config with default values and goes on its merry way with no problems.
What I have tried:
First:
Dim innerExcept As ConfigurationErrorsException = CType(cex.InnerException, ConfigurationErrorsException)
My.Computer.FileSystem.DeleteFile(innerExcept.Filename)
Then various combinations of the following:
My.Settings.Reset()
My.Settings.Reload()
My.Settings.Upgrade()
No matter what I try, I get the following error. Any thoughts?
System.Configuration.ConfigurationErrorsException HResult=0x80131902
Message=Configuration system failed to initialize
[truncated for brevity]
Inner Exception 1: ConfigurationErrorsException: '.', hexadecimal
value 0x00, is an invalid character.
I'm attempting to zip a folder containing subfolders and items, using Windows shell CopyHere command:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb787866(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/ms723207(v=vs.85).aspx
Update: Note, prefer a native solution-- this is for a distributed Excel VBA tool, so bundling 3rd-party files is not ideal. And, need synchronous compression.
I can easily add a folder and its contents to the zip:
oShell.Namespace(sZipPath).CopyHere "C:\My Folder"
So we know CopyHere can process multiple objects inside a folder in 1 statement.
The problem is, the above command puts the containing-folder at the root of the zip, and it's contents inside of it. But, i don't want the containing folder-- just its contents.
The doc mentions a wildcard (option 128), but when i use a wildcard, i get an error:
oShell.Namespace(sZipPath).CopyHere "C:\My Folder\*"
The file name you specified is not valid or too long.
Perhaps there's a way to use my 1st command above, and then move the items in the zip to the root of the zip?
It would be acceptable to loop through each item in the source folder, adding one at a time to the zip. But, because CopyHere is asynchronous, each subsequent CopyHere fails if the previous CopyHere is not finished. None of the fixes work for this issue:
Comparing number of items in source-folder and destination-zip fail, because if the zip contains a folder, that counts as only 1 item (the items it contains are not counted. https://stackoverflow.com/a/16603850/209942
Waiting a while between each item works, but a timer is unacceptable: it's arbitrary. I cannot guess in advance the size or compress-time of each object.
Checking to see if the zip is locked for access failed for me. If I block my loop until the file is not locked, I still get a file-access error. https://stackoverflow.com/a/6666663/209942
Function FileIsOpen(sPathname As String) As Boolean ' true if file is open
Dim lFileNum As Long
lFileNum = FreeFile
Dim lErr As Long
On Error Resume Next
Open sPathname For Binary Access Read Write Lock Read Write As #lFileNum
lErr = Err
Close #lFileNum
On Error GoTo 0
FileIsOpen = (lErr <> 0)
End Function
Update: VBA can call shell commands synchronously (instead of creating a shell32.shell object in VBA), so if CopyHere works on command-line or PowerShell, that could be the solution. Investigating...
Automating Shell objects really isn't a viable approach as you have already discovered. The Explorer Shell doesn't really expose this capability in any other manner though, at least not before Windows Vista and then not in any fashion easily used from VB6 programs or VBA macros.
Your best bet is a 3rd party ActiveX library, but be careful about 64-bit VBA hosts where you'll need a 64-bit version of such a library.
Another option is to acquire a later copy of the zlibwapi.dll and use some VB6 wrapper code with it. This is also a 32-bit solution.
That's what Zipper & ZipWriter, Zipping from VB programs does. Considering your requirements (which for some reason includes a fear of the Timer control) you could use the synchronous ZipperSync Class. See post #4 there. That code includes a simple AddFolderToZipperSync bundling up the logic to add a folder instead of just a single file.
The downside of the synchronous class is that a large archival operation freezes your program UI until it completes. If you don't want that use the Zipper UserControl instead.
You could also take the ideas from that to write your own wrapper class.
Solution:
Windows contains another native compression utility: CreateFromDirectory at a PowerShell prompt.
https://msdn.microsoft.com/en-us/library/system.io.compression.zipfile.createfromdirectory(v=vs.110).aspx
https://blogs.technet.microsoft.com/heyscriptingguy/2015/03/09/use-powershell-to-create-zip-archive-of-folder/
This requires .Net 4.0 or later:
> Add-Type -AssemblyName System.IO.Compression
> $src = "C:\Users\v1453957\documents\Experiment\rezip\aFolder"
> $zip="C:\Users\v1453957\Documents\Experiment\rezip\my.zip"
> [io.compression.zipfile]::CreateFromDirectory($src, $zip)
Note, you may have to provide the complete pathnames-- active directory was not implicit on my machine.
The above compression is synchronous at the PowerShell prompt, as the OP requests.
Next step is executing synchronously from VBA. The solution there is the .Run method in Windows Script Host Object Model. In VBA, set a reference to that, and do the following, setting the 3rd parameter of .Run command, bWaitOnReturn to True:
Function SynchronousShell(sCmd As String)As Long
Dim oWSH As New IWshRuntimeLibrary.WshShell
ShellSynch = oWSH.Run(sCmd, 3, True)
Set oWSH = Nothing
End Function
Now call SynchronousShell, and pass it the entire compression script.
I believe the only way for this process to work is if CreateFromDirectory is executed in the same session as Add-Type.
So, we must pass the whole thing as 1 string. That is, load all 4 commands into a single sCmd variable, so that Add-Type remains associated with the subsequent CreateFromDirectory. In PowerShell syntax, you can separate them with ;
https://thomas.vanhoutte.be/miniblog/execute-multiple-powershell-commands-on-one-line/
Also, you'll want to use single-quotes instead of double-quotes, else double quotes around the strings are removed when the daisy-chained commands are passed to powershell.exe
https://stackoverflow.com/a/39801732/209942
sCmd = "ps4 Add-Type -AssemblyName System.IO.Compression; $src = 'C:\Users\v1453957\documents\Experiment\rezip\aFolder'; $zip='C:\Users\v1453957\Documents\Experiment\rezip\my.zip'; [io.compression.zipfile]::CreateFromDirectory($src, $zip)"
Solved. The above constitutes the complete solution.
Extra info: Additional comments below are for special circumstances:
Multi-version .Net environments
If a .NET < 4.0 is the active environment on your OS, then System.IO.Compression does not exist-- the Add-Type command will fail. But if your machine has the .NET 4 assemblies available, you can still do this:
Create a batch file which runs PowerShell with .Net 4. See https://stackoverflow.com/a/31279372
In your Add-Type command above, use the exact path to the .Net 4 Compression assembly. On my Win Server 2008:
Add-Type -Path "C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.IO.Compression.FileSystem\v4.0_4.0.0.0__b77a5c561934e089\System.IO.Compression.FileSystem.dll"
Portability
Turns out, on my machine, I can copy the compression dll to any folder, and make calls to the copy and it works:
Add-Type -Path "C:\MyFunnyFolder\System.IO.Compression.FileSystem.dll"
I don't know what's required to ensure this works-- it might require the full .Net 4.0 or 2.0 files to be located in their expected directories. I assume the dll makes calls to other .Net assemblies. Maybe we just got lucky with this one :)
Character Limit
Depending on the depth of our paths and filenames, character-count may be a concern. PowerShell may have a 260-character limit (not sure).
https://support.microsoft.com/en-us/kb/830473
https://social.technet.microsoft.com/Forums/windowsserver/en-US/f895d766-5ffb-483f-97bc-19ac446da9f8/powershell-command-size-limit?forum=winserverpowershell
Since .Run goes through the Windows shell, you also have to worry about that character limit, but at 8k+, it's a bit roomier:
https://blogs.msdn.microsoft.com/oldnewthing/20031210-00/?p=41553
https://stackoverflow.com/a/3205048/209942
Site below offers a 24k+ character method, but i've not studied it yet:
http://itproctology.blogspot.com/2013/06/handling-freakishly-long-strings-from.html
At minimum, since we can put the dll wherever we like, we can put it in a folder near C: root-- keeping our character-count down.
Update: This post shows how we can put the whole thing in a script-file, and call it with ps4.cmd. This may become my preferred answer:
.\ps4.cmd GC .\zipper.ps1 | IEX
-- depending on answer here.
CopyHere:
Re the question: can CopyHere command execute on command-line?
CopyHere can be executed directly at PowerShell prompt (code below). However, even in powershell it's asynchronous-- control returns to PowerShell prompt before the process is finished. Therefore, no solution for the OP. Here's how it's done:
> $shellapp=new-object -com shell.application
> $zippath="test.zip"
> $zipobj=$shellapp.namespace((Get-Location).Path + "\$zippath")
> $srcpath="src"
> $srcobj=$shellapp.namespace((Get-Location).Path + "\$srcpath")
> $zipobj.Copyhere($srcobj.items())
When I attempt to compile a LESS template in Visual Studio using Web Essentials, I receive an error that says "Unexpected token u" with no file name, no line number, and no column number. Why is this happening?
Go to %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\12.0\Extensions which is the folder where per-user Visual Studio extensions reside. WebEssentials will be located in a subfolder with a randomly generated name.
From inside the WebEssentials folder, open up the file Resources\nodejs\tools\server\services\srv-less.js and go to line 65, which reads:
map = JSON.parse(output.map);
The problem is source map output may be the undefined value. JSON.parse can only parse strings, so it casts that to the string value "undefined" before parsing, but JSON does not recognize that as valid token. (It only understands the null value, not the undefined value.)
So... change line 65 to read:
map = JSON.parse(output.map || "null");
And voilà; LESS compilation on files with empty output works again.
Source:
https://github.com/madskristensen/WebEssentials2013/issues/1696
From my experience, this error occurs when LESS attempts to output a CSS file from a LESS file, and the resulting CSS file is empty. In my case, this happened after removing some font-face declarations, which left the resulting CSS file empty. LESS would not compile until I added a class that would output to the CSS file.
Details may be found here: https://github.com/madskristensen/WebEssentials2013/issues/1696
I'm adding this to StackOverflow because I'm unable to access Github at my workplace. I hope this helps someone.
You can also add in your less file an important comment /**/ or #charset "utf-8"; as described here https://github.com/madskristensen/WebEssentials2013/issues/1696
Hi community!
I have an application in VB.Net, in the user's computer is located in program files.
The users run always the program as an Administrators.
But in some cases; when the program try to rename a file in the program files the program throws the following exception:
The given path's format is not supported.
SOURCE = System.Security.Util.StringExpressionSet.CanonicalizePath
Also, happens when I try to copy a file.
The application does the rename or copy automatically and it's the same name for all the users
Example:
Rename(vOld, vNew)
FileCopy(vOld, vNew)
This exception only happen in Win7.
Somebody have an idea what is the reason to some users appear this exception?
This will happen when the user provides an invalid file name, for example one that includes colons.
You should validate that the user-entered file name does not contain any of the values in System.IO.Path.GetInvalidPathChars.
All it's my fault!
-_-'
I'm trying to rename this path:
C:\_MyFile.xlsx
To:
C:\MyFile.xlsx
In my computer all works fine because I have the both files (The users only has the file with the underscore).
When the program try to validate it try to rename the file "_C:\MyFile.xlsx" to "C:\MyFile.xlsx"
The exception don't give much information about my error...
Please have a look at the following code
with text_io;
use text_io;
procedure hello is
begin
put_line("hello");
new_line(3);
end hello;
When I click "build all" in GPS IDE, I get this error
gnatmake -d -PC:\Users\yohan\firstprogram.gpr
firstprogram.gpr:1:06: literal string expected
firstprogram.gpr:2:01: "end" expected
gnatmake: "C:\Users\yohan\firstprogram.gpr" processing failed
[2013-04-03 13:29:58] process exited with status 4 (elapsed time: 00.47s)
I am very new to Ada, as you can see, this is my first program. Please help.
On the command line, gnatmake will happily compile a file which contains Ada code but has the extension .gpr. GPS knows "better" than that, and insists on treating myfirstprogram.gpr as a GNAT Project file, which of course it isn't.
You'll find life with GNAT much easier if you stick with its file naming conventions: .ads for a spec, .adb for a body, and the file name needs to be the unit name in lower case. In your case, the file should have been called hello.adb.
The simplest approach to creating a GNAT project file in GPS is to go to the Project menu and select New. The only places where you must enter data are on the "Naming the project" page (you might choose firstproject!) and the "Main files" page, where you'd click on the blue + to add hello.adb; you can Forward through the others.
After adding the main file, you can click Apply to install the new project file; now you can Build all and Run.
You may find the GPS tutorial helpful (Help menu, GPS ...)