none
"StackHash" crashes

    Question

  • Hi all,

    this is probably not the right place for this question, but I'm giving it a shot anyway, counting on the fact that we have experienced people here who crash applications for a living 

    I recently noticed APPCRASH report data which specify something like "StackHash_1703" in the "faulting module" parameter of the Windows Error Reporting crash data. When this type of crash is reported, the fault offset in the module always seems to be 0.

    Fault bucket 42424242, type 1
    Event Name: APPCRASH
    Response: None
    Cab Id: 0

    Problem signature:
    P1: foo.exe
    P2: 1.42.42.42
    P3: 46b17782
    P4: StackHash_1703
    P5: 0.0.0.0
    P6: 00000000
    P7: c0000005
    P8: 00000000
    P9:
    P10:



    There does not seem to be a module (=DLL) called "StackHash", so I assume it rather specifies a special class of crashes. When I search the web, I find lots of other similar incidents, but (so far) no good explanation of what this crash class means. There seems to be at least a weak connection with DEP (data execution prevention) in practice, but this may be coincidental, of course.

    My current hypothesis is this:
    • The application crashes.
    • The kernel's top-level crash handler tries to walk the application's stack, or at least checks stack consistency.
    • The stack has been corrupted beyond recovery, or at least so badly that the faulting module cannot be determined anymore.
    • Lacking the module data, the OS crash handler inserts "StackHandler_xxxx" as the name of the faulting module, indicating that the stack has been corrupted. "xxxx" seems to vary and either indicates the type of stack corruption, or some kind of (hash?) value representing stack configurations.
    Any hints most welcome!

      Claus

    http://www.clausbrod.de/Blog

    • Moved by Max Wang_Chinasoft Tuesday, April 26, 2011 5:32 PM forum consolidation (From:Windows Error Reporting for ISVs)
    Monday, August 06, 2007 7:44 AM

Answers

  • Hi,

     

    In the OS when I try to get a faulting module name it is possible that there is no module laoded at that address. For example in this case the EIP was zero. So in those cases where a module is not loaded and it is not also in the unloaded module list, I take a stack hash of the stack so that we can identify this crash from other crashes where also the module is not known.

     

    Thanks

    Monday, August 06, 2007 5:03 PM

All replies

  • Hi,

     

    In the OS when I try to get a faulting module name it is possible that there is no module laoded at that address. For example in this case the EIP was zero. So in those cases where a module is not loaded and it is not also in the unloaded module list, I take a stack hash of the stack so that we can identify this crash from other crashes where also the module is not known.

     

    Thanks

    Monday, August 06, 2007 5:03 PM
  • Thanks a lot, now it all makes sense!

    If such a problem occurs "in the wild", would the Watson servers ever request the crash data from the customer system (provided, of course, that the application has been registered and mapped etc.)?

    Thanks!

      Claus

    Monday, August 06, 2007 5:45 PM
  • The data collection rules are the same for all events.  If you map the exe, we will set the rule to collect data.  There are some cases where the rule may not apply itself right away, and those events will show up in the WER Software application on https://winqual.microsoft.com having a red 'x' over the cab icon.  Simply click on that icon to put the server into collection mode for that event.

     

    Kind regards,

    -Jason

     

    Tuesday, August 07, 2007 3:43 PM