none
After installing KB2840149, Windows Server 2008 R2 is stuck in a reboot loop RRS feed

  • Question

  • On Windows Server 2008 R2, Windows Update is set to download updates but not install them until we tell it to. The only update available on this machine was KB2840149 (the fix for MS13-036). The update installed, but upon restart, the system gets stuck in a reboot loop. The startup screen displays "Preparing to configure your computer" for a few seconds and then automatically reboots. There does not appear to be a BSOD occurring because I disabled "Automatic Restart On System Failure". I cannot boot into Safe Mode because the same problem occurs even then (!!!!!), i.e., Windows tries to finish installing that update even when booting into Safe Mode.

    I've recovered the logs via a command prompt by booting to System Recovery Options. The Windows Update log confirms that that KB2840149 was the only update, and it installed successfully, requiring a reboot. The boot log (ntbtlog.txt) indicates that the system reboots at different points during driver loading. I saw no pattern to the reboots in that log.

    I've run chkdsk and System Startup Recovery. I deleted Windows\WinSXS\pending.xml. I also ran

    DISM.EXE /Image:F:\ /Cleanup-Image /RevertPendingActions

    (Note that after loading drivers during the boot to System Recovery Options, the system drive was assigned drive letter F:).

    Those steps did not fix the problem. Furthermore, DISM fails to set the Windows directory or mount the registry when I use the /Get-Packages switch, so I can't do any manual cleaning. Unfortunately, due to time constraints on task scheduling, only the databases on the machine have been backed up nightly. The last system image is six months out of date, and it appears that a bare metal recovery would take the same amount of time to get the system running again, about two days (the clerk responsible for doing the full backup is on my s**t list; he's lucky that I kept a spare server available just for this situation).

    I'll be grateful for any suggestions.

    Monday, May 27, 2013 10:18 AM

Answers

  • I found the problem. Among its other tasks, the server hosts an application that is shared on the network. Workstations map a drive letter to a share on the server in which the application is installed and run it from that mapped drive. The application (one could not say that it is written very well) requires all workstations to map to the same drive letter. In addition, in order to access the application for any purpose, the server must also use that drive letter to map to its own share. There are not services associated with the application. The share acts solely as a file share.

    Now, before you tell me that drive letters are mapped only in a user's hive and are not global to the system, let me say that I already know that.

    I discovered in the logs (which I had retrieved via the command prompt in a "Repair Your Computer" session) a reference to that application's share right before the machine looped back into the reboot.

    Removing the share fixed the problem. I booted to "Repair Your Computer", opened a command prompt, and ran Regedit, and loaded the System hive from its location on the hard drive. I deleted the share from

    HKEY_LOCAL_MACHINE\TEMPSYSTEM\ControlSet001\services\LanmanServer\Shares

    "TEMPSYSTEM" was the name that I gave to the loaded hive. After modification, I then unloaded it.

    I should note that the server had another drive letter mapped to a share on another computer, but that one caused no problem. I have no idea why this worked, but I verified that this was the problem by re-sharing the folder. I could reboot and log in to the machine. But when I re-mapped the drive letter, I couldn't even log in before the machine automatically rebooted.

    I admit that I have no idea why this worked. The fact that it rebooted prior to login (and prior to loading the user profile in which the drive was mapped) only when the drive letter was mapped is baffling to me. Frankly, I wish I'd never discovered this solution because it makes me dizzy. But, for what it's worth, there it is.


    Monday, March 24, 2014 2:50 AM

All replies

  • Thanks for your reply. Unfortunately, none of those suggestions worked. I've also ran:

         bootsect /nt60 sys /force

    to no avail. It looks like a bare metal reinstallation is my only option. Windows simply will not get through the "Preparing to configure Windows" phase without interrupting itself and rebooting.

    Friday, May 31, 2013 11:34 AM
  • I found the problem. Among its other tasks, the server hosts an application that is shared on the network. Workstations map a drive letter to a share on the server in which the application is installed and run it from that mapped drive. The application (one could not say that it is written very well) requires all workstations to map to the same drive letter. In addition, in order to access the application for any purpose, the server must also use that drive letter to map to its own share. There are not services associated with the application. The share acts solely as a file share.

    Now, before you tell me that drive letters are mapped only in a user's hive and are not global to the system, let me say that I already know that.

    I discovered in the logs (which I had retrieved via the command prompt in a "Repair Your Computer" session) a reference to that application's share right before the machine looped back into the reboot.

    Removing the share fixed the problem. I booted to "Repair Your Computer", opened a command prompt, and ran Regedit, and loaded the System hive from its location on the hard drive. I deleted the share from

    HKEY_LOCAL_MACHINE\TEMPSYSTEM\ControlSet001\services\LanmanServer\Shares

    "TEMPSYSTEM" was the name that I gave to the loaded hive. After modification, I then unloaded it.

    I should note that the server had another drive letter mapped to a share on another computer, but that one caused no problem. I have no idea why this worked, but I verified that this was the problem by re-sharing the folder. I could reboot and log in to the machine. But when I re-mapped the drive letter, I couldn't even log in before the machine automatically rebooted.

    I admit that I have no idea why this worked. The fact that it rebooted prior to login (and prior to loading the user profile in which the drive was mapped) only when the drive letter was mapped is baffling to me. Frankly, I wish I'd never discovered this solution because it makes me dizzy. But, for what it's worth, there it is.


    Monday, March 24, 2014 2:50 AM