Geoff Chappell - Software Analyst
The PROCESS1_INITIALIZATION_FAILED bug check reports a fatal error fairly late in the kernel’s initialisation.
| Bug Check Code: | PROCESS1_INITIALIZATION_FAILED |
| 1st Argument: | NT status code for operation that failed |
| 2nd Argument: | 0 for any failure of 2nd call to internal routine PsInitSystem;
2 for error when opening a system DLL; 3 for error when creating section for system DLL; 4 for error when accessing section for system DLL; 5 for error when mapping view of section for system DLL; 6 for error finding any of one set of functions in system DLL; 7 for error finding any of second set of functions in system DLL |
| 3rd Argument: | index to identify system DLL when 2nd argument is 2 (see below) |
| 4th Argument: | zero |
When the 2nd argument is zero, the cause really might be just about anything. Details may be documented here another time. The other cases are all concerned with so-called system DLLs. Though the code provides for more, there is presently only one, and it is of course NTDLL.DLL.
The following functions are required as exports from NTDLL to avoid case 6:
The NTDLL exports required for avoiding case 7 depend on a CPU feature, specifically support for the SYSENTER and SYSEXIT instructions:
The preceding description is of build 6.0.6000.16386 from the original Windows Vista. In earlier versions, the higher-numbered cases concerned with exports from NTDLL are interpreted a little differently:
| 2nd Argument | Corresponding Exports Required From NTDLL |
|---|---|
| 6 | LdrInitializeThunk |
| 7 | NPXEMULATORTABLE before version 5.1 |
| 8 | KiRaiseUserExceptionDispatcher KiUserApcDispatcher KiUserCallbackDispatcher KiUserExceptionDispatcher |
This arrangement does at least have the merit of acknowledging something quite special about NTDLL. It has no entry point for initial execution, as would ordinarily be defined in the executable’s PE header. Instead, NTDLL is started by calling its exported LdrInitializeThunk function.
This bug check is documented, though with all arguments except the first marked as reserved. The description of possible causes is very broad. This is strange, given the very specific causes that some Microsoft programmer has thought to distinguish through the 2nd argument. It’s not as if the documentation is just taking its time to catch up. This is old code. Use of the 2nd argument to elaborate problems with NTDLL.DLL dates from at least Windows NT 4.0. If you delete NTDLL.DLL, which does admittedly take some effort nowadays, then what you get for your pain is precisely this bug check with 2 for its second argument. Instead of talking vaguely about “a missing file from the boot partition”, why not document that if the second argument is non-zero, then the problem file is necessarily NTDLL.DLL?