locked
Service application crashing without WER dialog RRS feed

  • Question

  • I created a C# windows service and to crash my service application I run from elevated console following command:

     

    threadhijacker.exe /crash:av /tid:[thread id of service] /debugpriv

      

    It inject Access Violation to service and crash it, this cause cpu rich 100% and a dw20.exe process run in task manager but no WER dialog showed (Note: Vista error reporting Setting configured to show WER dialog.)

    Then I checked "Control Panel > System and Maintenance > Problem Reports and Solutions" history and found that one APPCRASH report created but not reported automatically.

     

    Please let me know:

     -Why WER dialog don't showed from service?

    or

    -Why APPCRASH don't reported automatically?

     

    Note: Our service run under local system account and allowed to interact with desktop.

     

    Thanks

    • Moved by Max Wang_1983 Tuesday, April 26, 2011 5:34 PM forum consolidation (From:Windows Error Reporting for ISVs)
    Saturday, June 23, 2007 12:36 PM

Answers

  •  

    Hossein,

     

    You may not see a WER dialog for crashing services. In the case where you do not see a dialog, the crash will not be reported. Periodically, you may be prompted to report any unreported crashes. The high CPU usage you're seeing is the dw20.exe process collecting additional crash information. It can be fairly CPU intensive. That information is queued for later reporting. Once the crash is reported, information will become available on http://winqual.microsoft.com after a few days. This is true for both managed and native crashes.

     

    In Vista it's highly encouraged that Windows services not communicate with the desktop, mainly for security reasons. Because of this you will not see a WER dialog if a service fails. If you'd like to debug your service, before injecting a fault you will have to attach a debugger or execute it from a non-service wrapper. You may find the articles below helpful with this.

     

    Debugging services with windbg: http://support.microsoft.com/default.aspx/kb/824344

    Debugging managed services with VS: http://www.ondotnet.com/pub/a/dotnet/2003/09/02/debuggingsvcs.html

     

    Claus,

     

    According to this section, Microsoft Error Reporting is expected to behave differently on Vista than XP and some of the configurations may not work as in previous operating systems. You're correct that services do not bring up a WER dialog for security reasons. However, both managed and unmanaged crashes are made available on http://winqual.microsoft.com without the need for specialized code or top-level exception handling.

     

    Thank you,

    -Saar Picker

    Developer Portal - http://winqual.microsoft.com

    Saturday, June 23, 2007 4:10 PM

All replies

  • Hossein,

    do you get the WER dialog if you run the service under your own account?

    From How to: Configure Microsoft Error Reporting: "Reports can be queued for three reasons: the user is offline, the application chooses to queue the report, or the logged-on user does not have sufficient privileges to view the report."

    And a little further below: "If the context of the application is different from the context of the user, then, for security reasons, Microsoft Error Reporting cannot show the user the report UI. For example, if a system service crashes and the logged-on user is not an administrator, Microsoft Error Reporting must suppress the UI at the time of the event and queue the report."

    Now, this description is for an earlier implementation of error reporting services, but the same security concerns probably still hold true for the latest WER implementation in Vista.

    Another idea: Maybe there are limitations for managed code. A quote from the same document: "Microsoft Error Reporting cannot support managed applications natively, but is designed for integration with the Common Language Runtime (CLR)." I'm not completely sure what this means and whether it still applies for the latest WER generation, but maybe it's a hint worth following up.

    Some links to discussions or articles which may also be relevant:
    Hmm... now that I found it, the video referred to in the second link might even be interesting for some of my own problems with WER.... Wink

      Claus
     

    Saturday, June 23, 2007 2:15 PM
  •  

    Hossein,

     

    You may not see a WER dialog for crashing services. In the case where you do not see a dialog, the crash will not be reported. Periodically, you may be prompted to report any unreported crashes. The high CPU usage you're seeing is the dw20.exe process collecting additional crash information. It can be fairly CPU intensive. That information is queued for later reporting. Once the crash is reported, information will become available on http://winqual.microsoft.com after a few days. This is true for both managed and native crashes.

     

    In Vista it's highly encouraged that Windows services not communicate with the desktop, mainly for security reasons. Because of this you will not see a WER dialog if a service fails. If you'd like to debug your service, before injecting a fault you will have to attach a debugger or execute it from a non-service wrapper. You may find the articles below helpful with this.

     

    Debugging services with windbg: http://support.microsoft.com/default.aspx/kb/824344

    Debugging managed services with VS: http://www.ondotnet.com/pub/a/dotnet/2003/09/02/debuggingsvcs.html

     

    Claus,

     

    According to this section, Microsoft Error Reporting is expected to behave differently on Vista than XP and some of the configurations may not work as in previous operating systems. You're correct that services do not bring up a WER dialog for security reasons. However, both managed and unmanaged crashes are made available on http://winqual.microsoft.com without the need for specialized code or top-level exception handling.

     

    Thank you,

    -Saar Picker

    Developer Portal - http://winqual.microsoft.com

    Saturday, June 23, 2007 4:10 PM