Access violation when running profiler

burns

I have an application that is running fine on its own (though a little slow at parts), so I ran it in the profiler. When I do so, I get the following exception:

Unhandled exception at 0x10008d56 in Application.exe: 0xC0000005: Access violation writing location 0x0b12c498.

The debugger claims to not have source for the location of the exception, so I'm just left looking at the assembly which doesn't mean too much to me.

Does this kind of behavior ring a bell to anyone? Any tips for how I could track down the problem?

I'm running a single-threaded application on x86 hardware running 32-bit Windows XP.

Chris.Allen

There's only one bell that this rings and that's the bell of DOOOM!! ;-)

Seriously- we're just going to have to debug this to find out exactly what has happened; there are so many reason why a profiled application may crash.

If you can obtain a mini-dump with this exception in it we will analyse it.

In the meantime, if you're not doing so already, use the "fastest, most accurate" profiling mode, this may help (it cuts down the overhead of the profiler).

burns

Could you help me figure out how to do that? I'm using Visual Studio 2008 Pro, and I'm coding in C#. I see the msdn instructions (http://msdn.microsoft.com/en-us/library/fk551230.aspx), but despite the grid at the top claiming that these instructions apply to C# Pro, it says a little lower that they apply only to native C++. And sure enough, when I look at the Debug menu when I'm running, there is no "Save Dump As" option.

Do you happen to know what the special magic is?

I tried "fastest, most accurate" and it no longer throws up the unhandled exception, but it also never brings up my main form. So . . . better . . . but not much. ;o)

Chris.Allen

I would advise obtaining the debugging tools for windows:

http://www.microsoft.com/whdc/devtools/ ... llx86.Mspx

(64 bit version also available).
Then using windbg.exe, attach the debugger to your process (File->attach to process), press F5 until you get the exception then, in the windbg command window type:

dump c:\dumpfile.dmp

Buuut, if you are not getting the crash, it may be best to bypass this and look at why it isn't loading the form. Do you get any errors in the windows application event log?