none
Desktop app continuously fails Windows 8 ACK on Crashes and Hangs test

    Domanda

  • Yesterday I submitted my app for Windows 7 logo certification, which passed the logo tests (with warnings). However, my app keeps failing to pass the Windows 8 desktop app logo certification test. I downloaded the latest App Certification Kit (2.2) from the SDK.

    My app consists of two EXEs and several DLLs. One of the EXEs is the user interface while the second EXE is a Windows service. My app is a system tool that monitors the health of hard disks and SSDs, and notifies the user if potential problems are detected. Because this is a system tool, the main UI's EXE is manifested to run as administrator--configuration is stored globally (per machine), plus being able to run disk tests through ioctl calls requires elevated perms.

    Most of the tests run without issue. There are a couple of warnings, but the Crashes and Hangs test ALWAYS fails when it tries to process the service executable. The report says that Windows Error Reporting detected that the EXE crashed or hung. Clicking on the help link gives a description of the test, and suggests I open the Applications and Services\Microsoft\Windows\Immersive-Shell log and look for events numbered 5900-6000. I don't have a log by that name, nor did I see any 5900-6000 events in ANY of the logs, and Windows 8 has many, many logs.

    In Windows Error Reporting's history, I didn't see any messages related to my service executable crashing or hanging. Furthermore, the main service EXE has debug logging code, and it writes serious exceptions to the Application event log. All of the debug logs generated during the certification test show normal activity -- the executable is started, one or more method(s) are called and the executable exits normally. No exceptions--handled or unhandled--are reported.

    I installed the App Verifier 6.2 (available from the SDK setup), and interestingly I found that my service EXE generates app verifier logs ONLY when run interactively from my user session. When the service is started/stopped via the Services MMC snap-in, I don't see anything logged in App Verifier. I see my UI executable there, as well as msiexec.exe, but not the service EXE.

    The service EXE is NOT manifested to run with elevated perms; it runs as invoker. Running it from the command line or double-clicking it displays the usual Windows message that services are not to be run directly, but rather run from the Services snap-in. The service runs as LocalSystem and it does perform operations that would require elevation--and LocalSystem runs with full system perms. If a user were to manually change the service account to a regular, non-privileged user, the service would still start (it would not crash), but there would be errors aplenty logged in the debug log file (if enabled) and the Application event log would also indicate the service was started with incorrect perms. In any case, it is designed NOT to crash.

    The successful creation of debug log files and the lack of errors posted by the service EXE suggests to me that the service is behaving normally. I cannot find anything that would lead me to believe the service EXE is hanging or crashing.

    One item I should note is that the computer is a member of a domain that has group policy, and one of the policy settings includes a logon disclaimer screen. I'm not sure if that could be throwing off the test.

    Matt

    martedì 8 gennaio 2013 18:27

Risposte

  • Solved!

    I decided to look deeper into the event logs, and I saw that the service in question crashed back in November, when I was doing some early testing. That's the only time the service ever crashed on that machine. I cleared the Application event log and re-ran the certification test without any changes, and it passed with flying colors.

    Lesson learned - always clear the logs before re-running the cert test. Maybe Microsoft should tweak the cert tool to ignore events that were generated prior to that test run, in case the tester forgets. :)

    giovedì 10 gennaio 2013 00:33

Tutte le risposte

  • I disabled the logon disclaimer screen. Unfortunately this did not change the outcome. The test log shows the same message that Windows Error Reporting detected a crash or hang on the service EXE.

    About 8 hours later, and still no luck. I changed the service properties so that it would handle power state changes, handle a shutdown event and more. This was based on googling the error text "executable was detected by Windows Error Reporting and experienced a crash or hang." Other folks, however, described seeing actual WER crash dumps and unhandled .NET exceptions in the application or system event logs!

    My computer is not showing ANYTHING in the application or system event logs suggesting any types of problems. In fact, everything in the event logs, as well as my custom debug logs, show that everything is working perfectly. No crashes, no unhandled exceptions, etc. Yet the ACK seems to insist that the service executable is crashing or hanging. Seeing that the problem is referenced in the WER Post Uninstall log file, I thought perhaps the service EXE wasn't shutting down fast enough so that perhaps even after Windows Installer completed the uninstall, the process hadn't exited yet, and maybe WER was complaining about that. That theory was not supported by Task Manager, which clearly showed the service process exiting normally and timely, but I still baked in a 2-second delay in the MSI just to be sure that the process exit wasn't the issue. A 2-second delay didn't help, nor did a 60-second delay.

    Here is a snip from the Log_WindowsErrorReporting_POSTUNINSTALL.xml file:

    <WexProperty 
    	BaseLvl="Msg" 
    	Priority="0x10000000"
    
    	UserText="OriginalName" CA="691559" LA="691665" >
    <Data>
    <WexTraceInfo ThreadId="9920" ProcessId="3892" TimeStamp="80754989416"/><WexValue><![CDATA[Microsoft.Windows.SoftwareLogo.Tests.WindowsErrorReporting.WindowsErrorReporting.ExecuteTest]]></WexValue>
    </Data>	<rti id="3049113769" />
    	<ctx id="660245962" />
    </WexProperty>
    <RTI ID="3188648473" Machine="MATT-PC" ProcessName="C:\Program Files (x86)\Windows Kits\8.0\App Certification Kit\TE.exe" ProcessID="3892" ThreadID="2976" BaseTime="2013:1:9 1:18:56:273" Frequency="2929628" />
    <Warn 
    	File="" 
    	Line="-1" 
    	UserText="Executable C:\Program Files\CompanyNameHere\ProgramNameHere\Program.Service.exe was detected by Windows Error Reporting and experienced a crash or hang." CA="6934028" LA="6934277" >
    <Data>
    <WexTraceInfo ThreadId="9996" ProcessId="8548" TimeStamp="80761231142"/>
    </Data>	<rti id="3188648473" />
    	<ctx id="660245962" />
    </Warn>
    <EndTest 
    	Title="Microsoft.Windows.SoftwareLogo.Tests.WindowsErrorReporting.WindowsErrorReporting.ExecuteTest" 
    	TUID="" 
    	Result="Fail" 
    	Repro="" CA="6989101" LA="6989226" >
    <Data>
    <WexTraceInfo ThreadId="9920" ProcessId="3892" TimeStamp="80761286970"/>
    </Data>	<rti id="3049113769" />
    	<ctx id="660245962" />
    </EndTest>

    And here is the content of the post_process_trace_WindowsErrorReporting_182013_201854.txt file.

    program Error: 0 : 1/8/2013 8:18:56 PM ERROR:WindowsErrorReportingExecutable C:\Program Files\CompanyNameHere\ProgramNameHere\Program.Service.exe was detected by WER.
    program Error: 0 : 1/8/2013 8:18:56 PM ERROR:WindowsErrorReporting Task failed due to one or more failing executables.

    As you can see, the test says something went wrong, but without any crash data or WER logs, it's impossible to know what the test isn't liking. This very same installer passed the Windows 7 logo cert, also using the ACK 2.2, without any trouble.

    • Modificato Matthew H. Sawyer mercoledì 9 gennaio 2013 01:41 Additional diagnostic details.
    martedì 8 gennaio 2013 20:48
  • Solved!

    I decided to look deeper into the event logs, and I saw that the service in question crashed back in November, when I was doing some early testing. That's the only time the service ever crashed on that machine. I cleared the Application event log and re-ran the certification test without any changes, and it passed with flying colors.

    Lesson learned - always clear the logs before re-running the cert test. Maybe Microsoft should tweak the cert tool to ignore events that were generated prior to that test run, in case the tester forgets. :)

    giovedì 10 gennaio 2013 00:33