Jump to content











Photo
- - - - -

Server 2012 R2 Unable to start


  • Please log in to reply
9 replies to this topic

#1 MrDragonsEye

MrDragonsEye
  • Members
  • 4 posts
  •  
    United Kingdom

Posted 07 July 2018 - 08:19 PM

Hi,
I recently uninstalled ImDisk using Revo Uninstaller Pro Portable and I now recieve a "INACCESSIBLE_BOOT_DEVICE" BSOD every time the server starts up.
I've tried placing all the instalation files and drives back onto the disk on another machine, but the machine still cannot start.
I did this by extracting the ImDiskTk-x64.exe file using 7-Zip and then copied all the files in the relevant sections on the un-bootable drive such as:
C:\Program Files\ImDisk
C:\Windows\System32
C:\Windows\System32\drivers
C:\Windows\SysWOW64
I found the location of each file by searching for the files on a working install of ImDisk on another machine.
 
I've tried (what I think is) all of the usual steps to try resolve2012 R2 startup issues such as startup repair "last known good configuration", safe mode, system restore, "SFC /scannow", "BOOTREC /rebuildbcd", "BOOTREC /fixmbr", and "BOOTREC /fixboot".
All of these commands have been ran in the pre-boot enviroment built into 2012 R2, as well as from a recovery CMD from the "Repair my PC" section of the installation ISO.
And when trying to boot into safe mode or any other mode, the BSOD still comes up after the whirling cirlce goes around for 15-20 seconds.
 
This server is installed and setup in UEFI boot.
 
Is it possible that I didn't properly uninstall the tool, and it's now affected Windows?
The only reason I used the 3rd party uninstaller tool was because I couldn't unmount the RAM disk with the configuration tool as it stated a driver error that I can't remember unfortunately, something about a file missing.
 
Any advice would be greatly appreciated as my server will no longer boot and I can't think of anything else to try. I really really do not want to rebuild this server as I have a lot hosted on here.


#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 08 July 2018 - 09:45 AM

It is unlikely that the uninstallation of IMDISK (unless you had it for some RAMdisk booting setup or however with automount/reconnect and startup settings) would affect the booting, but of course everything is possible, particularly if you attempted to uninstall it while there was a volume mounted..

 

You mentioned Imdisk-Tk, is that the IMDISK Toolkit (which is NOT (only) IMDISK)? :unsure:

 

If what you had installed was the Imdisk Toolkit (AND it was set to automount/autocreate a RAMdisk at startup) then it is instead likely that an incorrect uninstall left over some "automatically running commands" (that don't work now because the corresponding files are gone in the meantime).

 

JFYI, the BOOTREC commands were/are unneeded, as they fix parts of the booting process that come BEFORE the "whirling circle".

 

Hopefully v77 (the developer of the IMDISK Toolkit) will see this thread and provide some assistance, very likely you will need to edit the (offline) Registry to remoe or change some keys.

 

If you could disable automatic reboot and post the actual STOP ERROR of the BSOD it might help to understand if it is disk driver related (typically 0x0000007b, but other STOP ERRORs may be compatible with the issue).

 

:duff:

Wonko


  • Olof Lagerkvist likes this

#3 MrDragonsEye

MrDragonsEye
  • Members
  • 4 posts
  •  
    United Kingdom

Posted 08 July 2018 - 03:42 PM

Hi, thank you for the response.

Yes, I had "ImDisk Toolkit" installed, didn't realise that was a different version, apologies.

 

Thank you for the clarification regarding the BOOTREC commands, I was just wanting to try it in cast, but didn't know it wasn't necessary.

 

Hopefully v77 can help me out here with any (if at all) registry items to recreate, and how I would be able to do that to an offline Windows disk.

 

I thought I already disabled automatic reboot before all of this happened. Clearly it doesn't work here because it reboots anyway. Please can you advise how this can be disabled on a system that won't boot?

I'm also going to follow Wizard's suggestion here of enabling boot logging and checking the Ntbtlog.txt

https://sourceforge....hread/05501fe7/



#4 MrDragonsEye

MrDragonsEye
  • Members
  • 4 posts
  •  
    United Kingdom

Posted 08 July 2018 - 04:14 PM

Okay, so I managed to disable automatic restart on system failure inside the F8 recovery section, and here's a picture of it.

 

The fact that it can't even "collect some error info" (stops at 0% and would then reboot) is even more worrying, leading me to believe that it's not dumping anything like logs to the drive for later searching.

 

Apart from C:\Windows\Minidump, do you know of anywhere else that BSOD logs or dumps are written that I can check?

 

And as you can see, there's also no error code, apart from the type of error.

https://i.imgur.com/a3Xs5YA.jpg

 

a3Xs5YA.jpg



#5 v77

v77

    Silver Member

  • Team Reboot
  • 602 posts
  •  
    France

Posted 08 July 2018 - 04:40 PM

The Toolkit only adds user mode services. Even if they are not properly uninstalled, there is nothing that could create a BSOD.
But I wonder... Did you change the Temp environment variables to a ramdisk that no longer exist? If yes, you should try to restore them, but you will need a tool to edit the registry of the server.

(Great screenshot by the way... As always, Microsoft provides a lot of helpful informations when we really need them... -_-)


  • Olof Lagerkvist likes this

#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 08 July 2018 - 04:57 PM

Yep :), but it's the same, good ol' 0x0000007b error of previous Windows versions, which  was connected to  the "INACCESSIBLE_BOOT_DEVICE", *like*:

https://www.techsupp...indows-startup/

 

Unlike what reported there the INACCESSIBLE_BOOT_DEVICE (in typical MS style) doesn't really mean "inaccessible boot device" but more generally that *something* (related to EITHER RAM OR to a disk related driver) went *somehow* wrong.

 

In other words it tells us "nothing" more, but confirms that the issue is likely related to the (failed) uninstall of the Imdisk Toolkit.

 

What is happening - more or less - is that there is (in the Registry) a service in the booting sequence set as "boot" or "autostart" (or one of the similar "early" flags) that the system cannot find anymore (because it has been deleted during the uninstall attempt) and that creates the issue.

 

The possible solutions are:

1) re-add everything (both files and Registry entries) that the uninstaller deleted.

or:

2) delete from the Registry the entry(ies) that refer to the (now not existing anymore) service/driver/whatever.

 

#1 is more complex (and takes much more time) but it is relatively easy to perform by *everyone* (you can "diff" a brand new, temprary install of the OS in a VM with the same after having installed the IMDISK Toolkit)

#2 should be "easy" but we need to understand exactly what to touch (or not to touch)

 

The NTbtlog may (or may not) give some more info on the driver/service/whatever that failed to load, this doesn't always happen but since you got up to the "whirling circle" it is possible that it actually logs the failure naming the actual driver.

 

To edit the (offline) Registry is not particularly difficult, you can use your "normal" install CD (which loads a PE) and from it run RegEdit, mount the offline hive and do the modifications or - alternatively - use the offline registry tool our friend erwan.l developed.

 

The problem is to understand WHICH modifications are needed, as fiddling with the Registry should be something done only once we are very sure about what to do.

 

In any case, the first thing that needs to be done is to backup (before attempting any edit to the Registry) to backup the Registry "backing files":

https://docs.microso.../registry-hives

that are normally:

 

"%USERPROFILE%ntuser.dat"
"C:\Windows\System32\Config\SOFTWARE"
"C:\Windows\System32\Config\SYSTEM"
"C:\Windows\System32\Config\SECURITY"
"C:\Windows\System32\Config\COMPONENTS"
"C:\Windows\System32\Config\SAM"
"C:\Windows\System32\Config\DEFAULT"

+ the \boot\BCD, so that they can be restored as they are now in case of issues with the edits.

 

The only backing files that probably need to be edited are only SOFTWARE and SYSTEM, but to be on the safe side it is better to backup all the ones in \Config\.

 

Only good for NEXT time (and JFYI):

http://reboot.pro/topic/20848-dumpreg/

 

:duff:

Wonko

 

P.S. If the issue is the setting of the %TEMP% as v77 suggested, the setting should be in either:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Environment

or:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Control\Session Manager\Environment

(check the HKEY_LOCAL_MACHINE\SYSTEM\Select key to know which ControlSet is CurrentControlSet)

in keys TEMP and TMP (the default value being a REGEXPAND_SZ "%SystemRoot%\TEMP")



#7 MrDragonsEye

MrDragonsEye
  • Members
  • 4 posts
  •  
    United Kingdom

Posted 08 July 2018 - 06:05 PM

The Toolkit only adds user mode services. Even if they are not properly uninstalled, there is nothing that could create a BSOD.
But I wonder... Did you change the Temp environment variables to a ramdisk that no longer exist? If yes, you should try to restore them, but you will need a tool to edit the registry of the server.

(Great screenshot by the way... As always, Microsoft provides a lot of helpful informations when we really need them... -_-)

I don't remember setting any custom TEMP variables.

I will have just left it default which looks to be "Create TEMP Folder" ticked, and the default variables for both User and System being "%USERPROFILE%\AppData\Local\Temp" and "%SystemRoot%\TEMP" respectively.

 

 

The possible solutions are:

1) re-add everything (both files and Registry entries) that the uninstaller deleted.

or:

2) delete from the Registry the entry(ies) that refer to the (now not existing anymore) service/driver/whatever.

 

#1 is more complex (and takes much more time) but it is relatively easy to perform by *everyone* (you can "diff" a brand new, temprary install of the OS in a VM with the same after having installed the IMDISK Toolkit)

#2 should be "easy" but we need to understand exactly what to touch (or not to touch)

I think I would prefer option two in this case, removing what the uninstaller failed to do because of the still mounted drive, and thus completely uninstalling it, leaving Windows to hopefully load normally.

 

Unfortunatley, as tried here: https://sourceforge....hread/05501fe7/Enabling Boot logging dosen't seem to be working because I can't find a ntbtlog.txt file in C:\Windows, which is frustrating because that could've provided info on what exactly it's trying to load and failing on.

 

With regards to editing the offline registry files, I can load into the install disk (PE) and run "regedit", I assume that would work? How would I then switch to viewing and editing of the offline "C:" disk, and not the X: disk that the PE runs in?

 

And once I am in and have opened the offline registry of C:, what keys and folders am I looking for? Seen as I can't get the boot logging and ntbtlog to work. Should I just start searching for references to ImDisk, the developer/program name, as well as all of these driver files and start deleting keys and items?

imdisk.inf

awealloc.sys

imdisk.exe

imdisk.cpl

imdisk.cpl.manifest

imdsksvc.exe

imdisk.sys



#8 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 09 July 2018 - 07:34 AM

Yep, that (searching for connected names) is the idea, but I would have liked to have a list of the keys affected by the install.

 

The procedure to edit "normally" an "offline" Registry is:

1) boot from a PE

2) press SHIFT+F10 to open a command prompt

3) run Regedit.exe

4) load (temporarily) a hive backing file under HKLM, callling it - to make it simple - OFF_<backingfilename>, i.e. load SOFTWARE calling it OFF_SOFTWARE, etc.

5) search in it for any reference to the files that may create the issue
6) delete or change settings in the keys/entries

7) unload hive

 

Here is a "generic" howto (windows 7, but 10/server 2012 shouldn't be different):

https://www.wintips....gistry-offline/

 

In any case FIRST make a copy of the hives that you will edit.

 

As said most probably the only two hives that need to be edited are SOFTWARE and SYSTEM (that loosely form the HKLM hive in the Registry).

 

Besides searching for imdisk, you might need to check the item founds and do searches for references found in the results.

 

There is the possibility that *something* is set to autostart (or similar) through a mechanism outside the Registry, but that should (once possible issues in the Registry are solved) be possible to bypass booting in Safe Mode.

 

:duff:

Wonko



#9 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

Posted 10 July 2018 - 04:15 AM

@MrDragonsEye
Does the Uninstaller created a log file?
May be a additional setting/file is removed. Can be a Upperfilter or Lowerfilter at registry.

Another approach:
Dism /Add-Driver install drivers to a offline windows.
https://docs.microso...e-windows-image
Which hardware do you use? Which mass storage controller do you use?
  • Olof Lagerkvist likes this

#10 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1448 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 10 July 2018 - 10:52 AM

Windows cannot save any logs or dumps when INACCESSIBLE_BOOT_DEVICE happens, because it does not have any disk volume where it could save anything in that case. The only way to analyze deeper in that case in by attaching a kernel debugger which could then extract a dump to the debug host. But that's a lot more complicated thing.

 

My "best guess" is something like what cdob says too, that something with the boot disk drivers were destroyed at some point so that Windows does not load all drivers necessary to access the boot disk when starting up. Typically, comparing UpperFilter and LowerFilter registry values for certain devices in the device tree with another machine with similar setup that works correctly could be one way to solve this.






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users