On my corporate machine I had the issue where Windows would either:

1. Endlessly show the “Shutting Down” screen.
   OR   
2. When initiating a shutdown, nothing would happen except that Winlogon.exe would take a 100% CPU utilization on a single core.

I realized that when I didn’t use a hibernate file (powercfg /h off) scenario 2 would happen.

Troubleshooting the first scenario:

When troubleshooting the first scenario I configured the registry keys as described in “Windows feature lets you generate a memory dump file by using the keyboard” as can be found here. In order to get a full memory.dmp I configured the registry like described in KB254649.
After that I initiated a shutdown and waited for a few minutes before creating a memory dump by holding down the right CTRL key and pressing the SCROLL LOCK key two times.

After rebooting the machine there was a file C:\Windows\Memory.dmp ready to be analyzed in the Windows Debugger. The interesting stack (thanks Rob Scheepens) turned out to be:

…
  |    |    WINLOGON.EXE!ShutdownWindowsWorkerThread
  |    |    |- WINLOGON.EXE!IsHiberboot
  |    |    |    |- FMIFS.DLL!QueryIsDiskCheckScheduledForNextBoot
  |    |    |    |    |- FMIFS.DLL!QueryIsDiskCheckScheduledForNextBoot
  |    |    |    |    |    |- FMIFS.DLL!InvokeAutoChk
  |    |    |    |    |    |    |- IFSUtil.DLL!IFS_SYSTEM::QueryCorruptionState
…

I wasn’t sure why it was checking whether CHKDSK was scheduled for a next boot. 

Troubleshooting the second scenario:

Since I also noticed the “IsHiberboot” part in the stack of the previous scenario, I enabled my hibernation file to check if this was to blame (using “Powercfg /h on").

After initiating a shutdown, nothing would happen except that winlogon.exe would take a 100% usage on a single core. After giving my PC a cold-reset I troubleshooting this using the following steps:

Note: If you don’t have the Windows 8 Performance Recorder installed, consult my previous blog for instructions:

http://blogs.technet.com/b/home_is_where_i_lay_my_head/archive/2012/07/30/how-to-install-the-windows-8-performance-recorder.aspx

I started Windows Performance Recorder, pressed Start and initiated a shutdown, waited a few minutes and finally pressed Save. 

The result was a .ETL file which I loaded in Windows Performance Analyzer.
We already know the problem is related to the process winlogon.exe as shown in Task Manager, so we need symbols to get more information. To configure this use “Trace/Configure Symbol Path” and entered the Microsoft Public Symbol path:

Now looking at the trace, we can confirm it’s winlogon.exe taking a 100% CPU usage on a single core:

Zooming in on the responsible thread and doing some stackwalking, the same stack was to blame:

Because the stack is identical to problem troubleshooted in scenario 1, we can confirm it’s the same issue.

So what do we do next?

The thing I didn’t understand was the QueryIsDiskCheckScheduledForNextBoot part.
I looked in my registry to see if any CheckDisks (chkdsk) was scheduled and found this entry:

I searched the registry for HarddiskVolume7 but couldn’t find any other entry and realized this was a VHD that was mounted a while ago.

Turned out to be that in the past:

• I mounted a VHD
• The volume got the dirty bit set
• Before rebooting I dismounted the VHD again.

I followed up with the developers responsible for this code, turns out there might be a bug in autochk where it is not properly handling an explicit request to check a volume that no longer exists. This is currently being investigated.

The workaround is simple, remove this line from BootExecute:

autocheck autochk /m /f \Device\HarddiskVolum7

If this info has helped you, please consider leaving a comment.