NS_I_NOLOG_STOP (0X400D2F01) on IIS Startup — What Forces a Pending Header Switch

When This Appears

You'll see NS_I_NOLOG_STOP (0X400D2F01) in the Windows System event log or in the IIS log file right after restarting the IIS service (iisreset), rebooting the server, or cycling the HTTP service (net stop http /y then net start http). The message reads something like: "Forcing a switch to a pending header on start". It's most common on Windows Server 2012 R2 through 2022, and occasionally on Windows 10/11 with IIS enabled.

Root Cause

What's actually happening here is that HTTP.sys — the kernel-mode driver that handles all HTTP traffic — keeps a log of every request it processes (if IIS logging is enabled). When you restart the service, HTTP.sys tries to close the current log file and open a new one. If there's a pending log file switch that didn't finish cleanly (say, from a previous crash or forceful shutdown), HTTP.sys logs NS_I_NOLOG_STOP to say: "I was supposed to switch log files at a specific time or size, but I'm starting up now, so I'll just force the switch immediately."

This is purely informational. The code 0X400D2F01 falls in the success/informational range for NT status codes (bit 29 is set). Microsoft's documentation literally says it means "No logging will stop" — meaning the logging service is acknowledging the switch and moving on. It's not an error you need to fix. The real problem? It often scares admins who see a cryptic hex code and assume something's broken.

When It's Actually a Problem

Skip the panic unless you also see a real error like NS_ERROR_LOGGING (0x8007052C) or NS_WARN_LOG_FILE_CORRUPT (0x8007052D) in the same log. If those appear, your log file path might be inaccessible or the disk is full. Otherwise, treat NS_I_NOLOG_STOP like a background noise — it's the system saying "done, moving on".

How to Verify It's Harmless

The fix is really about confirming the message is benign. Here's what to check in order:

1. Check the event log details. Open Event Viewer (eventvwr.msc), go to Windows Logs → System, filter by source HTTP or IIS. Look for 0X400D2F01. If the level is Information (not Warning or Error), you're fine.
2. Verify IIS logging is enabled. Open IIS Manager, select your server, double-click Logging. Ensure the directory exists and is writable. Default is %SystemDrive%\inetpub\logs\LogFiles. If the path is missing or read-only, you'll get real errors later.
3. Check disk space on the log drive. Log files can fill up fast under heavy traffic. Run dir "%SystemDrive%\inetpub\logs\LogFiles" /s to see sizes. If you're below 5% free space, extend the volume or move logs to another drive via IIS Manager → Logging → Browse.
4. Review HTTP.sys log settings. Open an admin command prompt and run netsh http show log. Look for LogFileRolloverStyle — if it's set to Size (default is Daily), the switch might happen more often. That's fine, but check the LogFileDirectory value matches IIS's setting. If they differ, you'll get a real error, not this informational message.
5. Reboot and reproduce. Force a clean cycle: net stop http /y, then net start http. Then check the event log again. If only 0X400D2F01 appears with no accompanying errors, you're done.

If It Still Appears After All That

If you're still seeing this message frequently and it's bothering you (or your monitoring tools), you can suppress it in Event Viewer by creating a custom view that excludes source HTTP with event ID 400D2F01. But honestly, the better approach is to educate your team that NS_I_NOLOG_STOP means nothing is wrong. The reason step 3 works is that disk space pressure can cause real log failures — but that will produce a different error code entirely. This one is just HTTP.sys cleaning up its own internal state.

Microsoft's own documentation (KB 973797, though old) confirms this is a status code, not an error code. The 0x400D prefix flags it as success with informational data. So relax — your IIS is fine. Move on to the actual problems.