Code and image signing troubleshooting
To troubleshoot code signing issues, you should have an understanding of how both test and retail signing works. See these topics for more information:
Different image build types demonstrate different code signing behaviors. To troubleshoot code signing, an understanding of the build types and the package creation process is also recommended. See these topics for more info:
You can use the SignTool to investigate how binary files are signed. For more info, see "Troubleshooting signing errors" in Sign binaries and packages.
Preloaded application troubleshooting
For preloaded applications to install in OOBE and appear in the application menu, test signing must be enabled in the build, or the packages must be retail signed.
| Symptom | Cause | Solution |
|---|---|---|
A preloaded XAP does not appear in the application menu. |
A retail image is being used and the package hasn’t been retail signed. |
Use a TEST, HEALTH, PRODUCTION or SELFHOST image or submit the packages to be retail signed by Microsoft. |
Other XAP signing issues also cause the preloaded application to not appear; these include:
Not all DLLs, MUI, and winmd files are signed in the XAP, or the XAP itself is not signed.
The self-signed certificate is not valid on the date that is set on the device during OOBE.
The app is using a second-party capability but is signed using third-party self-signed certs.
For information on signing, see Code signing.
Other typical issues that generate this same symptom include a missing license file or having an incorrect product ID in the provxml file.
Package deployment troubleshooting
For packages to be installed using the IUTool, test signing must be enabled in the build, or the packages must be retail signed.
| Symptom | Cause | Solution |
|---|---|---|
Using IUTool to deploy a package results in an error. |
A retail image is being used and the package hasn’t been retail signed. |
Use a TEST, HEALTH, PRODUCTION or SELFHOST image or submit the packages to be retail signed by Microsoft. |
Native driver kernel code troubleshooting
To load properly, native driver kernel code must be embedded signed as described in Code signing. To troubleshoot issues with drivers not being properly signed, debug statements from the code integrity components can be used.
To enable break on errors, and display debug message from the CI (Code Integrity) component, you can add the UMCIAuditMode registry entry to this subkey:
HKLM\System\CurrentControlset\Control\CI
Set the DWORD registry value DebugFlags to 0x00000011. This will cause driver signing failures to force a break into the debugger environment.
To see the output of a failed driver, enable debug output.
| Symptom | Cause | Solution |
|---|---|---|
Boot-critical driver does not load; the OS may appear locked during startup and the OS does not complete loading. |
Boot-critical driver is not embedded signed. |
Embed sign the boot-critical driver as described in Code signing. |
User-mode and kernel-mode code troubleshooting
User-mode code must be embedded signed or placed in a package that is catalog signed. To troubleshoot code signing, the debugger can be used.
The following debug statements display information about signing failures.
DbgPrintEx(DPFLTR_DEFAULT_ID, DPFLTR_ERROR_LEVEL, "[%wZ]:", &FileName);
DbgPrintEx(DPFLTR_DEFAULT_ID, DPFLTR_ERROR_LEVEL, "[%wZ] 0x%x > 0x%x\n", ProcessName, RequestedSigningLevel, *ValidatedSigningLevel);
These signing codes can be used to determine if the code is signed in the properly:
0xC =Windows signed
0x8 =Microsoft signed
0x2 =Unsigned
The following are example error codes that may be displayed with some types of code-signing problems.
In the first example error message, SVCHOST.EXE is launching clientshutdown3.exe. clientshutdown3.exe is supposed to be Windows signed(0xc), but it is incorrectly Microsoft signed(0x8).
[\Device\HarddiskVolume6\SharedData\PhoneTools\11.0\CoreCon\bin\clientshutdown3.exe]:[\Device\HarddiskVolume3\Windows\System32\SVCHOST.EXE] 0xc > 0x8
In the second sample, clientshutdown3.exe is supposed to be Windows signed(0xc), but it is incorrectly Microsoft signed(0x8).
[\Device\HarddiskVolume6\SharedData\PhoneTools\11.0\CoreCon\bin\clientshutdown3.exe]:[\Device\HarddiskVolume3\Windows\System32\SirepServerPlatDev.exe] 0xc > 0x8
These statements can be used to display Windows code integrity errors caused by incorrect code signing.
DbgPrintEx(DPFLTR_DEFAULT_ID, DPFLTR_ERROR_LEVEL, "******************************************************************\n");
DbgPrintEx(DPFLTR_DEFAULT_ID, DPFLTR_ERROR_LEVEL, "* This break indicates this binary is not signed correctly: %wZ\n", &FileName);
DbgPrintEx(DPFLTR_DEFAULT_ID, DPFLTR_ERROR_LEVEL, "* and does not meet the system policy.\n");
DbgPrintEx(DPFLTR_DEFAULT_ID, DPFLTR_ERROR_LEVEL, "* The binary was attempted to be loaded in the process: %wZ\n", ProcessName);
DbgPrintEx(DPFLTR_DEFAULT_ID, DPFLTR_ERROR_LEVEL, "*****************************************
| Symptom | Cause | Solution |
|---|---|---|
User-mode code that is copied to the phone does not run and returns an error. |
TestSiging is not enabled and the user-mode code is not embedded signed or it is not in a package that is catalog signed. |
Sign the user-mode code or place it in a package and catalog sign it as described in Code signing. |
Image signing troubleshooting
In this situation, the image FFU file needs to be code signed with keys that are aligned with the secure boot keys.
| Symptom | Cause | Solution |
|---|---|---|
When flashing an image, the FFUTool fails with an error message:
An 0x18 event is posted in the .etl log, representing a signature check failure. |
Secure boot is enabled on the phone and the image has not been signed with a certificate that chains to the UEFI PK boot key that an OEM provisions. |
Sign the image with a certificate that chains to the UEFI PK boot key. |