Shutdown reason codes are reason codes, not error codes or HRESULTs

A customer liaison asked the following question on behalf of his customer:

My customer is finding that their Windows Server 2003 system has restarted, and they want to find out why. I've found some event log similar to the ones below, but I don't know what error code 0x84020004 is. I've searched the Knowledge Base but couldn't find anything relevant. Please let me know why the system restarted.

Event Type: Information
Event Source: USER32
Event Category: None
Event ID: 1074
Date: 3/20/2009
Time: 11:51:30 AM
User: GROUP1\infraadmin
Computer: DATA2
The process Explorer.EXE has initiated the shutdown of computer SYSP1 on behalf
of user GROUP1\infraadmin for the following reason: Operating System: 
Reconfiguration (Planned)
Reason Code: 0x84020004
Shutdown Type: restart

The value 0x84020004 is not an error code. It says right there that it's a reason code:

Reason Code: 0x84020004

The system shutdown reason codes are documented in MSDN under the devious heading System Shutdown Reason Codes. In this case, the value 0x84020004 is a combination of

SHTDN_REASON_FLAG_PLANNED               0x80000000
SHTDN_REASON_FLAG_CLEAN_UI              0x04000000 // reason.h
SHTDN_REASON_MINOR_RECONFIG             0x00000004

That value for SHTDN_REASON_FLAG_CLEAN_UI is missing from the MSDN documentation for some reason, but's listed in reason.h. The flag means that the system was shut down in a controlled manner, as opposed to SHDTN_REASON_FLAG_DIRTY_UI which means that the system lost power and did not go through a clean shutdown.

In other words, this was a planned shutdown that was the result of an operating system reconfiguration. Perhaps somebody changed a system setting in the Control Panel, and in response to the question "The change you made requires that the system be restarted. Restart now?", the person said Yes.

Comments (21)
  1. Anonymous says:

    And of course, the error code is explained in much detail in the line before.

  2. Dan Bugglin says:

    Though to be fair I suppose "Operating System: Reconfiguration (Planned)" isn't the CLEAREST message in the world.

  3. Anonymous says:

    When is a Windows (Server) available that doesn't need to be restarted? (Serious question)

  4. Anonymous says:

    @Dominik: When someone gets the pure guts to write an in-memory patcher for NTOSKRNL.

    Since this is closed source, probably never.

    Disclaimer: I don't use it on Linux even though it is available.

  5. Anonymous says:

    I concur that it's a subtle labeling issue. The designer of this panel must have thought that it was obvious the "Reason Code" label would convey that the reason code was a numeric version related to the content of the "Description" field. Much better would have been to relabel "Description" to "Reason Explanation", or maybe relabel both "Long Description" and "Short Description". In any case, use the labels to make it obvious that the contents were dirctly related.

    UI design always seems simple until you have to do it right.

    [I guess it wasn't obvious to people who don't see these messages: The text is formatted (including the labels) by Event Viewer. The event source doesn't control how its log entry is presented. -Raymond]
  6. Anonymous says:

    I'd have told the customer that his computer restarted because the little person inside it got hiccups and had to go for a quick lie down.

    It wouldn't have needed Microsoft's involvement at all, and everyone would've been happy.

  7. DWalker59 says:

    AND, the Event Type of the record is Information, not Error.  There are lots of informational entries in the event log.  Some of them even contain those confusing hex codes.

  8. Anonymous says:

    Dominik: if you don't reboot after a patch, you can't guarantee that all processes are using the newly patched DLL and not the older insecure DLL. In other words, until you reboot, you haven't completed patching.

    The only difference from Linux in this regard is that Linux trusts admins to simply shut-down and restart any app that relied on the buggy DLL manually. If the Linux admin doesn't do this, well, then the problem's the same as in Windows– the patch is ineffective.

    Until we have radical new operating system technology, this isn't likely to change.

  9. Dan Bugglin says:

    Yeah really: "Why did the system restart?  There's plain English text in here but the hexadecimal numbers are confusing me!"

    I find it interesting though that the customer saw the hex number and immediately assumed it was the same thing as a BSoD STOP code or error code.  I guess it's because BSoDs are, unfortunately, familiar with users*.

    * – Though not with this user.  Only time I've seen Windows 7 BSoD is with a third-party virtualization product triggered by an obscure guest OS CD boot.

  10. Anonymous says:

    @James Schend

    "Until we have radical new operating system technology, this isn't likely to change."

    Josuhua referrer already to it. But for linux something like KSplice exists ( This patches the currently running linux kernel with the latest patches without doing reboots.

    If it can be done for the kernel (the heart of the system), surely it can be done too for the .DLL's (or .so's in linux's case). Although I dont think its worth all the effort. A downtime of 3 or 4 minutes when applying security patches isn't that bad, and surely you have more than 1 server running that can serve your data… (At least a backup server that can take temporarily control of things)

  11. Anonymous says:


    On Linux you could do this kind of live patching for userland with something like uprobe. That's not really what it's designed for and I wouldn't really recommend doing that, but it's possible.

  12. Anonymous says:

    That's right. If you can't deal with a planned downtime of a few minutes, how do you handle an *unplanned* downtime?

  13. Anonymous says:

    @James — The Linux systems I've used have usually been able to work out which running processes are effected by an update and restart only those.  And in the end, you can always just do 'for f in /etc/rc2.d/S*; do $f restart; done', which ought to restart everything without needing a reboot.  Windows Server really needs a way of doing this kind of thing.

    @Nathan — the problem is, such a tool needs in-depth knowledge of the process it's updating.  If any data structures change in layout, for example, it needs to be able to find them and update their layout dynamically.  You can't just assume that you can update the code and leave the data untouched; all kinds of stuff would probably crash.  The reason you can do it with the Linux kernel is that the kernel maintainers appear to be highly averse to changing any data structures without good reason.  Few other developers have this kind of discipline.

  14. Anonymous says:


    When someone gets the pure guts to write an in-memory patcher

    for NTOSKRNL.

    I remeber reading some article that Microsoft DOES have this technique and could use it in hotfixes: The DLLs shipped with windwos would contain some buffer area where the start of affected routines could be moved to do in memory patches.

    Unfortunately I cannto find the article anymore. Would be great if Microsoft really used this

  15. Anonymous says:

    Seems to me that the customer (/liaison) equates the format "0x8*******" with "error code", rather than "32-bit hex value whose meaning depends on context".

  16. Anonymous says:

    @Jules: If you're going to go through all your rc scripts and restart everything, then the only benefit you're getting from avoiding a reboot is the ability to brag about your incredible system uptime. Except that the services that the system is meant to provide weren't available continuously, as they were restarted. It always confuses me when Linux advocates use uptime as a measure of anything. Whenever they do a large-scale system update, they end up restarting pretty much all of their daemons, X, and all of the applications they were working with. Technically, they didn't reboot their computer. Realistically, they had to restart all of their applications, which works out to the same thing.

    As Raymond (or Larry Osterman, I forget which) mentioned in a previous article, Windows does have the ability to replace files that are currently in use (the main reason for requiring reboots after an update – recent versions of Windows seem to have the ability to unload most drivers and update them and restart them). It chooses not to, because the alternative would leave the system in an inconsistent state until you reboot.

    I've actually experienced this – run the multitude of windows updates required on a clean install of Server 2003 from remote desktop, then, without rebooting, login to the console with a user that hasn't logged into the server before. You'll get a bunch of errors when Windows prepares the local account, because Windows updated the files that it could replace, and left the others for after the reboot – as a result, there are a bunch of mismatched dll's calling each other.

  17. DWalker59 says:

    I think I mentioned once before, it is obviously possible to change all of the bits in computer memory from any given (current) state to any new desired state.  So, in-place matching is possible.

    However, it's almost infinitely complex to figure out how to map the bits for any given, running computer's Windows system (regardless of what Microsoft and non-Microsoft programs are running) into what it should look like after the updated modules are loaded.  You would need some way to map any and all possible arrangements of code and in-memory data structures to their new layouts like you would get after a reboot.  It's not worth the tremendous effort that it would take.

  18. DWalker59 says:


  19. Anonymous says:

    Reason Code: 0x95030005

    Magic White Smoke Depleted

    Please Insert More Cash*

    *Not aimed directly @ Microsoft; this redux can be applied to everything technical IMO

  20. Anonymous says:

    Once again msdn docs fail. Can't trust it.

  21. Anonymous says:

    What gets me is when I log into a server and receive the "this server shutdown unexpectedly" window and it asks me to fill in the information including a "Reason Code".  The reason code field is a text box.  I suppose a responsible admin should go to MSDN to look up the value for SHDTN_REASON_FLAG_DIRTY_UI.

Comments are closed.