Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a problem with an application we've made that sometimes crash with a StackOverflowException in some .NET code.

Unfortunately, the app is partly unmanaged and partly managed, and for some reason the problem only exhibits itself on non-developer machines.

My current plan is to use WINDBG (part of the Debugging Tools for Windows from Microsoft), installed on the testers machines, I can get WINDBG to trap the creation of the exception in question.

As such, I can do the following:

sxe ld:mscorlib
g
.loadby sos clr
!stoponexception -create System.StackOverflowException
g

Unfortunately, since this problem only crops up every other day, and only every 50+ execution or so, I'd rather avoid having the testers having to type in all or part of this for every time they start this app.

I tried placing the above commands in a text file and created a shortcut for them like this:

"...\windbg.exe" -c "$<c:\windbg.txt" -o "...\app.exe"

This starts the WINDBG debugger, but unfortunately fails with this error message:

0:000> sxe ld:mscorlib
0:000> g
Command file caused an implicit wait
Command file execution failed, HRESULT 0x80004005
    "Unspecified error"

So apparently, g is not allowed in such a startup script.

Is it possible to do what I want? Can I automate this, or do I just have to prepare a batch file or something that uses autohotkey that does this?

share|improve this question

You could try .dump /ma /u c:\app.dmp so that you get a crash dump which can be copied and analyzed on your machine.

However, instead of trying to let the user run WinDbg on his machine, you can take a crash dump automatically using WER, copy it to your machine and then analyze without time pressure. See Collecting user-mode dumps to create settings in the Registry which store the dump on disk.

In both cases you should copy from C:\Windows\Microsoft.NET\Framework\v4.0.30319 (or Framework64):

Otherwise it might happen that your .NET version differs from his version and you can't analyze the bug.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .