none
Experiencing "hard" crash in production -- no dmp file RRS feed

  • Question

  • Greetings,

     

    I have an application that was written in C# .NET 2.0 and it uses a DLL (3rd party library) that is a .NET wrapper around native code.  Very rarely, I get a hard application crash (the kind with the red "X" and no option to debug -- basically telling you you're screwed).  I used to get a Dr Watson dmp file but the last few times it's occurred, I have not -- I checked the AeDebug\Debugger registry value and it is "C:\WINDOWS\system32\drwtsn32.exe" -p %ld -e %ld which I thought was the necessary value for Dr Watson to create a dmp file.

     

    Even more strangely however (and this may explain the lack of a .dmp file) in my Administrative Tools-->Event Log I don't see an "Application Error" -- and for all previous crashes where a .dmp file was generated, I'd see an Application Error in the log.

     

    I'm wondering if this error sounds to you like something resulting from the DLL's manage-to-unmanaged code routines.  Usually when a crash occurs in managed code (dereferencing a null pointer for instance) I get the nice "Application has performed an illegal operation, would you like to debug" or something along those lines.  I'm also wondering if anyone out there knows why I might not be getting a .dmp file generated when this crash occurs.

     

    I'd love to be able to run this app on the production system in debug mode as I'm sure that would help me see into the crash better, but I cannot because this is a trading application and speed is of utmost importance. 

     

    If anyone has any ideas as to (a) if this sounds like some unmanaged code exception and (b) why it might not be generating a .dmp file, it would be greatly appreciated.

     

    Thanks,

    Rick

    Thursday, April 10, 2008 6:43 PM

Answers

  • Hi Rick,

    that is a tough problem. I have heard at the TechEd from Mark Russinovich that this can happen when the stack has been corrupted so that no stack walk is possible. When this happens on a XP machine no dump is written. You could try to let your application run on Windows Vista where in (nearly) every case a dump file should be written. A little Google search did show that if the disk miniport driver or one of the affected components has changed its checksum after the boot also no dump file is written to prevent file system corruption.
    If I were you I would give Vista a try or you add tracing to your application so you can narrow the sitation down which action can cause this problem when the system is under stress.

    Yours,
       Alois Kraus

    Thursday, April 10, 2008 8:25 PM