views:

92

answers:

3

I don't know if I'll pass all the necessary information here, but I've only been asked to post this question here and I'm not entirely onto the matter.

There is a .NET Framework 2.0 application compiled in the Debug mode with the parameter jitDebugging set to true in app.config

<system.windows.forms jitDebugging="true" />

After any crash we get the dialog box allowing us to send a report or to debug the program. When we choose to debug and select proper VS, the IDE starts but with the announcement:

No symbols are loaded for any call stack frame. The source code cannot be displayed.

and

Disassembly cannot be displayed in run mode.

Is there any possiblity to see the code or the spot where the crash has occured?

//edit:

Tarscher's advice was fine, but the final solution was to... add a module with the Main() method and force project to use it - somehow thanks to that VS was able to display code and locate exception's source.

+1  A: 

Your .net application will create a dump file after the crash. You need to load this dump file together with the application pdb file to see your source code. This pdb files are created when compiling and store debugging information about a program.

In your case Visual Studio might not be able to locate the pdb files and load them.

Tarscher
I guess you meant dump file, not dumb file :-D
0xA3
fixed the 'typo' :-)
Tarscher
Hmm and where should I look for this 'dumb' ;) file? And load it with the app how...?
brovar
The problem is that windows will delete it if you exit the crashed application. Thus you need locate it and copy it to make sure it isn't deleted. I haven't found any information on where to find the file but do a *.dmp search of the harddisk.
Tarscher
+2  A: 

make sure you have .pdb files along with your .dll files in your application.

derek
Been there, done that.
brovar
+1  A: 

Not sure what your deployment scenario looks like, but running a debugger on a customer or production machine isn't typically very practical. Write an event handler for the AppDomain.UnhandledException event and display the value of e.ExceptionObject.ToString(). At a minimum, your customer can send you a screen shot. You'll get the exception message and a nice stack trace, showing how your program got in trouble. Usually 95% good enough to see what went wrong.

Hans Passant
Unfortunately, we're in those 5%.
brovar