BSOD when trying to boot in safe mode - Windows 7 x86

xilolee said:
Did you try this?

xilolee said:
Open regedit, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot and check if that one is present as a sub-key or as a value...
If it's there, try to rename it.
Click to expand...
Click to expand...

The driver c2scsi.sys was not present in the key. After my lasst changes, the Roxio SoftScsi Host Adapter (X86) listed in device manager under Storage controllers is showing "Windows cannot start this hardware device because its configuration information (in the registry) is incomplete or damaged. (Code 19)". I don't recall if I tried booting into safe mode after the changes I made so I'll give that a try.
 
dxdiag shows these roxio files/codecs:
Read More:
You can try to remove them with these commands, one by one (from an elevated command prompt):
Read More:
Or with this command (All previous commands concatenated in one):
Read More:
 
Is it reasonable to believe the BSOD when trying to boot into safe mode might be caused by one of the leftover Roxio files listed above? Wouldn't it seem to be the Sonic Solutions (Roxio) sahdia32.sys driver that's still part of my hard drive driver list?
 
I believe I have found the root cause of my BSOD during safe mode driver loading. The problematic driver was asyncmac.sys. The driver provider is Microsoft, file version 6.1.7600 16385 (win7_rtm 090713-1255). The file is not corrupt. I'm not sure if Roxio had anything to with the problem, but at least I have finally rid my system of it.
 
Glad you found the culprit! :)

The SC tool "says" it is "RAS Asynchronous Media Driver".
Instead on internet I found they say it's "MS Remote Access serial network driver".

How did you find it? And how did you disable it? SC tool?
 
I was trying to get Sysinternal's process monitor to do boot logging in safe mode, but never got it to capture the events prior to the BSOD. In the process of reviewing ntbtlog.txt to see if it was loading its driver, I noticed that asyncmac.sys was often the last driver loaded in a number of boot events, and suspected those log entries were associated with my safe mode boot BSOD experiments. I changed its driver name hoping it would be sufficient to keep it from loading in safe mode and that worked.

I might have been able to use Sysinternal's Autoruns tool to disable it, but changing its name was the first thing that came to mind, and I wasn't all that familiar with Autoruns. That might have been a better approach because right now Device Manager is showing the RAS Async Adapter as having a problem (Code 32), and trying to update its driver has been unsuccessful so far. I suspect it may not be an important adapter right now, so I've just disabled it for the time being. I'm guessing its an issue with identifying the right .inf file for its driver.

I'd be interested in hearing any thoughts or comments on the process I used, especially to know is what I did is technically sound and not just a fluke. I was trying to recreate the safe mode BSOD by reinstalling the driver to confirm it as the root cause of fault when I ran into the problem updating its driver, and right now it has dropped to a lower priority. I do recognize that recreating the fault by installing its driver is the last step in confirming it as the root cause, and once it bothers me enough knowing it's still a loose end (I HATE LOOSE ENDS!), I'll post an update here.

Thanks again for all of the help Sysnative's staff has given me. I learned a lot in the process, and that's as important to as is finding the cause. For me, any day that I learn something makes it a good day, no matter what else may have happened that day.
 
Back
Top