0xC0000001 boot loop and session initialisation failures on Windows Server

Fix it now

0xC0000001 is STATUS_UNSUCCESSFUL – the requested operation was unsuccessful. It is the most generic status Windows has and it names nothing. The useful information is the bug check the automatic restart is hiding. Stop the loop, read the real stop code, and start work from that.

bcdedit /set {default} recoveryenabled Off
bcdedit /set {default} bootstatuspolicy IgnoreAllFailures
bcdedit /enum

1. Boot from Windows Server installation media and choose Repair your computer, Troubleshoot, Command Prompt.
2. Run the commands above, restart, and write down the exact stop code and parameters now shown. That is the fault; 0xC0000001 was only the wrapper.
3. If the code is 0x00000032 or 0x0000006F, read parameter 1. On both, it is an NT status code that says why initialisation failed, and it is the only thing on the screen that identifies anything.
4. Confirm the boot entries are sane in the bcdedit /enum output: device and osdevice must name the partition that actually holds Windows.
5. Check the file system with chkdsk X: /f, using the letter the recovery environment assigned rather than assuming C.

Put the recovery behaviour back when you are finished: bcdedit /set {default} recoveryenabled On and bcdedit /set {default} bootstatuspolicy DisplayAllFailures.

If the exposed stop code has a clear owner – a driver, a hive, a volume – you now have an article to read about that. If not, the next section maps each companion code to the point in startup it belongs to.

Why it happens

Windows starts in stages. The boot manager hands over to the boot loader, which loads the kernel and the boot-start drivers. The kernel then runs its initialisation phases, bringing up memory management, the object manager, the registry and the rest of the executive. Only then does the session manager start, create session 0 for services and session 1 for the console, and hand over to the logon process.

0xC0000001 is published as STATUS_UNSUCCESSFUL, with the text that the requested operation was unsuccessful. That is all it says. Two servers showing this code can have entirely unrelated faults, and searching for it produces advice for every one of them at once. The first job is therefore not to fix anything; it is to make the machine show you what actually failed.

The companion codes are more specific, but less specific than they are usually made out to be. 0x00000032, PHASE1_INITIALIZATION_FAILED, means system initialisation failed, and parameter 1 is the NT status code describing why. 0x0000006F, SESSION3_INITIALIZATION_FAILED, is published as the initialisation of the Windows operating system failing, again with an NT status in parameter 1 – not, as it is often described, the session manager failing to start a particular subsystem. 0x00000033, UNEXPECTED_INITIALIZATION_CALL, has a name and nothing else: Microsoft publishes no description, cause or resolution for it and notes that it appears very infrequently.

On servers the component that changed is rarely a consumer-style driver. It is a storage controller driver, a firmware update that changed the controller mode, an agent that installs a boot-start filter, a hive damaged by an unclean shutdown, or a guest moved to a host whose storage stack does not match. Work through what changed rather than through everything that could theoretically be wrong.

Full reference

What each code marks

Two of the four carry an NT status in parameter 1, and that is where the real content is. A stop screen showing 0x00000032 with a parameter of 0xC0000034 is telling you an object name was not found; the same code with 0xC000009A is telling you an allocation failed. Those are different problems with different fixes, and the bug check number alone cannot distinguish them.

Boot repair command reference

Repair or restore

On a server with a current system state or full backup, restoring is often the better decision and it is certainly the more predictable one. Hand-repairing a boot failure can take hours with no guarantee at the end. Repair is the better choice when the backup is old, when the fault is clearly one update or one driver, or when the machine holds a role that is awkward to restore – a domain controller in particular, where a whole-image restore has consequences a system state restore does not.

Do not copy registry hives over existing ones without keeping the originals, and do not run repair operations against a volume on a disk you already suspect. Image the disk first if the data matters and there is no current backup.

Confirming the machine is genuinely healthy afterwards

• Put the recovery behaviour back. A server left with recoveryenabled Off will sit on a stop screen rather than restarting, which is often what you want on a machine with out-of-band management – but it should be a decision, not a leftover.
• Run Get-Service | Where-Object {$_.StartType -eq 'Automatic' -and $_.Status -ne 'Running'} and account for anything that did not start.
• Watch the System log for new BugCheck entries with ID 1001 over the following day.
• On a clustered node, weigh leaving automatic restart off against how quickly you want a failed node out of the way.
• Re-apply anything you removed, one item at a time, so the server ends up in a supported state rather than a working one.

Every code this article covers

Confirm the fix worked

1. The server restarts twice and reaches the sign-in screen both times without intervention.
2. The recovery behaviour has been restored, or left off deliberately and recorded.
3. bcdedit /enum shows device and osdevice naming the volume that actually holds Windows.
4. No automatic-start service is stopped without a reason you know.
5. No new BugCheck entries with ID 1001 appear in the System log over the following day.

Questions people ask about this