I want to run the Visual Studio debugger on a .Net program that has been obfuscated. (It's my own program - I'm not trying to crack someone else's program.)
When I compile the program with "System.Diagnostics.Debugger.Break()", or if I attach the debugger to the running process, then the debugger shows "No Source Available". This I understand - there is no source that corresponds to the obfuscated version of the program. But when I click "Show Disassembly" it shows a Disassembly window with "No disassembly available."
Why? Any suggestions as to what I can do to get the disassembly to work?
Under Debug Options I do have "Enable address-level debugging" and "Show disassembly if source is not available" checked.
Thanks.
EDIT
Just to try to explain a bit more ...
The program in question is my own program, and the obfuscation program being used is also my own program. The obfuscation program runs ILDAsm.exe, modifies the ILAsm code, and runs ILAsm.exe.
My obfuscation is apparently introducing problems so the program no longer works correctly. To understand how/why it isn't working I'd like to trace it. But for some reason Visual Studio debugger says "No disassembly available", and then I can't do anything at all. (When the non-obfuscated program is run under Visual Studio the Disassembly window can be opened and shows the expected information. It's only the obfuscated version that produces this problem with VS debugger.)
EDIT 2
Haven't been able to find an answer to my question, but I do have a sort of workaround now.
I've installed WinDbg and confirmed that it can attach to my obfuscated program and can at least single-step it and show the current execution location in a disassembly window. But I've never used WinDbg before, and it looks a bit daunting.
I've also followed the advice seen several places to load sos.dll into WinDbg. Maybe that will help.
But I'm guessing that what I'll actually end up doing is throwing lots of temporary logging statements into my program around the places where it's not working, and hopefully gain some understanding that way.
OK, I happened to stumble on what I was doing wrong.
As I mention in the first edit of my question, my obfuscation is being done by running ILDAsm.exe, modifying the ILAsm statements, and then running ILAsm.exe. It turns out I was missing the /Debug option on the ILAsm.exe run. So even though my Visual Studio builds were Debug builds, the JIT conversions at run time were Release/Optimize conversions.
With /Debug specified on ILAsm.exe I'm getting a PDB file, and when Visual Studio debugger connects to my program I'm getting IL source code display and, if I request it, disassembly display too! So now all is well!
Related
Every time I try to run my code, I am having this error: "Csc.exe" exited with code - 255.
I removed and re-installed Visual Studio 2015 and it did not help.
Does csc.exe succeed with different code?
It is possible that you’ve found a bug in the compiler that causes it to crash when trying to compile your particular program. To see if this is the case, create a new “Console App” project with Visual Studio (VS) and see if the default app in the template compiles and runs. If that works, then your code might be triggering a csc.exe crash. If that doesn’t work, your VS install might be completely broken in which case I would recommend uninstalling and reinstalling VS (but you already tried that). If you cannot get VS to run even simple programs on your computer, you’ll need to try to track down why it is crashing and see if it is something you can manually fix. If your system is messed up enough and it is not worth tracking a fix down, you might consider reinstalling Windows (using the “Reset” feature).
Another thing to try is running your code on another computer with VS installed. That can help determine if the issue is your code triggering a compiler error versus your computer being messed up.
If csc.exe only crashes for your particular code, then that is a bug in csc.exe. If there is an issue with your code, csc.exe should generate a nice error explaining the issue with your code instead of crashing.
It is also possible that your code is valid but a compiler bug causes csc.exe to crash. An example of this (with VS 2017 and csharp7) is roslyn#19182. If this is the case, you might try using the VS feedback (frowny face/feedback button in the upper right hand corner) feature to report the issue so that the VS developers know about it. Also, you might be able to poke your code around until suddenly VS starts running successfully. If this is the issue, it might be hard to guess why csc.exe is crashing, but, if you can, try to isolate the issue. For example, if csc.exe was running fine before you made some changes to your code, look at the changes you made and see if undoing them results in csc.exe running successfully again. Then try to make a new, minimal repro which causes csc.exe to crash and send that as feedback using VS’s feedback mechanism or by reporting a bug against the roslyn project. You might also ask a new question here about why that particular code causes csc.exe to crash. With particular code, people might be able to guess why csc.exe can’t handle it and suggest workarounds to use while waiting for the VS team to release a fix.
As it is, your question does not have enough information to guess why csc.exe was crashing for you. Hopefully this answer provides some guidance on what steps you should take if you ever end up in such a situation.
i coded a big project in c++ that runs when I open it in Debug or Release Mode, but when i open it without Debugging (ctrl + f5) it crashs after 5 seconds. It just doesn't reply anymore and is tagged as inactive in taskmanager. I tried to analyse the error with the windows debugger tools and application verfier, but i found nothing. Even when I set the "_NO_DEBUG_HEAP=1", the error doesn't occur, it just happens when I start it with ctrl + f5 or outside from visual studio. I'm not even sure if the _NO_DEBUG_HEAP works... Anyone have an idea what could be wrong ?
Any number of things may cause this.
Based on my passed experience, I suggest tackling this by removing code until the behaviour disappears... then determining why removing the code in question corrected the behaviour. (the removed code may not have been the cause, only a catalyst for the symptom)
If I was tasked with taking a quick glance to spot the error, I would think to look for buffer overrun related issues. This type of error has more safeguards in debug than executing a final build. That's just a stab in the dark based on buffer overruns being a common issue that kinda fits the symptom.
-dm
Common things to check:
Are you sure your application is setting any memory used to zero,
if it is assuming the memory has to be zeroed out?
Visual Studio might be initializing the memory given to the
application.
Is all the memory allocated being deallocated?
There are no un-initialized pointers being used?
There are no un-initialized variables being used?
64 bit exe crashing outside visual studio but working inside visual studio
Does the problem only happen on one computer?
You can use check_heap to check the validity of the heap
in the program:
Program crashes only in Release mode outside debugger
You can use the Windows debugging tools to show heap
corruption - there is a tool called "gflags" that comes with the
Microsoft "Standalone Debugging Tools for Windows"
https://msdn.microsoft.com/en-us/windows/hardware/hh852365
This URL shows how to run gflags against your .EXE:
Visual Studio - how to find source of heap corruption errors
I'm using Visual Studio 2008 to compile and debug a plugin for an application that runs under Windows.
The plugin has some problem and it crashes. I have been running VS in Debug mode but when the application crashes VS stack trace has nothing from my code. It is possibly the application itself that crashes. So I though I could try to figure out which part of my code does something the host application doesn't like by sprinkling a few print statements here and there in my code. That generally works as expected on *nix systems but in Windows I can't find where the output of those print goes. Can anybody point me in the right direction?
Also, if using prints do debug is too 1970's and somebody knows a better way to figure out where too look when the stack trace doesn't reveal anything interesting please let me know.
If i know correctly, debug.print is only executed when a debugger is attached, otherwise it is lost. (this applies to c# and vb.net).
You can use a logger to log your problems to some database or text file. A like NLOG to do the simple "log to a txt file" job. Additionally, you do not need to remove your logging code when shipping your addon -simply supress logmessages with low debug level.
Also, you could log to the windows event log, but is cluttered ny boatloads of junk, so you might have a hard time to differentiate that output.
Eventlog: http://support.microsoft.com/kb/301279
I am trying to run a project in Visual Studio 2010, and for some reason it seems like I can't... the command-line window is closed instantly and the debug info is the following:
'exercise01.exe': Loaded 'E:\e\work spaces\C++ projects\exercise01\Debug\exercise01.exe', Symbols loaded.
'exercise01.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', Cannot find or open the PDB file
'exercise01.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', Cannot find or open the PDB file
'exercise01.exe': Loaded 'C:\WINDOWS\system32\msvcr100d.dll', Symbols loaded.
The program '[5900] exercise01.exe: Native' has exited with code 0 (0x0).
what might be the cause for these two dll's to not get loaded? and is the fact program exited with code 0 related to my program not running, or is there another problem?
I know others have published such questions before, but unfortunately I couldn't fine any useful info anywhere, so forgive me if I'm re-uploading a question... I'm pretty much a noob when it comes to programming in C, and in Visual Studio in general, so please have patience (:
thank you :)
First thing to check: Are these files actually there. Maybe windows is installed in a different directory and an environment variable is pointing to the wrong place.
If the files are there it is probably an authentication problem. You are running from the command line window. You may be running this in the context of NETWORK SERVICE. Try starting the command window, by right clicking on the menu and selecting "run as administrator".
Basically, your program was started and quickly ran to completion.
When you start debugging a console mode VS project, if your program doesn't stop somewhere or hit a breakpoint, it'll just run the program and when the program exits the window will close.
This is different behavior than if you run the program without the debugger - VS will keep the console window open when the program terminates.
Anyway, you can wither set a breakpoint on main() (or some other convenient location) or instead of simply starting the program with the debugger, you can "single step" into it, which will immediately break into the debugger and stop executuion.
c++ with visual studio 2008
if i use assert() from assert.h and compile in debug mode, the application crashes if the assert condition doesn't hold and it prints me in the console on what line in what file this happened. that's quite useful, but i'd prefere to trap into the debugger at this position instead, if the condition doesn't hold
how can I do that?
thanks!
Try running your program under a debugger. Also, if you have a JIT debugger registered with the OS, then this should actually invoke said debugger. If you are on a Windows machine, take a look at this MSDN article or this post.