Kernel error 41

You receive those 'errors' when removing external devices, yes. For example, I get that error when removing USB's even WHEN ejecting safely.

I'd ask for the older dumps, but they are older dumps. We've already gone through various troubleshooting steps so taking a look at older dumps won't do us much good and may confuse us more. If and when you crash again, please attach the newest dump and we'll go from there.

Regards,

Patrick

Hi Patrick,

thanks for your help again. I kept driver verification running over the weekend. Still no problems. I turned it off to work properly (clicking on a folder took more than 5 seconds to open it).

1. My system also created a full memory dump (about 700 MB). Would this be helpful to you? What is the security aspect of a full memory dump? Would it be possible to extract passwords from it (maybe certain services are wrongly programmed and keep password unencrypted in memory). In any case I think it would not be good to publish a public download link. What are your thoughts?
2. It seems my system is slower than usual booting up. After the login I see a black screen with the mouse cursor for quite a while. Do you have instrutions on how to check the boot times of the various services and drivers? Since I'm at home and not connected to the office network the system can't connect to the NAS network shares and booting up will be longer. I still think it takes much longer than usual.
3. I would like to learn more about todays driver and system troubleshooting options. I worked for Microsoft as a freelance in Germany for 15 years until 2000. Then I turned my hobby "Swing Dancing" into my job and have not much time for playing around with the systems anymore. Can you recommend a good source or book? How did you gain all of your knowledge?

Cheers and all the best!

Marcus

Hi,

Good on disabling it, indeed verifier does begin to slow your system to a screeching halt after some time.

1. A Kernel memory dump would be very helpful as it contains all of the memory the kernel was using at the time of the crash. For example, you cannot analyze or debug a CLOCK_WATCHDOG_TIMEOUT bugcheck for example unless it's a Kernel or Full memory dump as you cannot check the stacks from the various processors if it's a muli-processor system, etc.

With this said, if someone is skilled enough, depending on what memory the kernel was using at the time of the crash, they could be able to extract whatever it may have been. I absolutely understand not wanting to publicize something like that if it's your wish. If you'd like, you can email me the dump. My email is listed on my BSOD blog link within my profile here. I'd post the email here, however I cannot as it filters them.

2. You can try a clean boot and then afterwards one at a time add the various 3rd party startup items or services you may use. It's a bit lengthy in terms of troubleshooting, but that's what troubleshooting is all about sometimes.

Perform a clean boot - http://support.microsoft.com/kb/929135

3. I've been around computers mostly all of my life, so any of the knowledge I have has been picked up over the years. With blue screens and analyzing Windows, etc, that has been a heavy hobby of mine for about two years now. I've constantly read and studied.

As far as books go, here are three I read often:

Windows Internals, Part 1: Covering Windows Server 2008 R2 and Windows 7

**** Windows Internals, Part 2: Covering Windows Server® 2008 R2 and Windows 7

**** Advanced Windows DebuggingThe books are a great reference and resource, however I have truly gained most of my knowledge from analyzing and debugging the dump files myself over the past few years. I've essentially made blue screens my life for a long time now. It's the hands-on experience that really helped, for me at least. **** I really enjoy it, and there's still so much to learn.****Regards,

Patrick****

Hi Patrick,

thanks for your thorough answer and your book recommendations.

Just a few minutes ago I had another BSOD. I just typed in text into an aspx-page in Visual Studio. Unfortunately Driver Verfication has been turned off already.

I checked the mini dump folder, but there was no new dump. Even the one dump that is there is dated July 29th. So apparently the dump I sent you was not the latest one. In the system and recovery dialog debug information was set to save memory dump and not mini dump. Still there was also no memory.dmp this time (I moved the old one to another folder to protect it from being overwritten). I set the

What is also strange is that in the system and recovery dialog the automatic reboot is turned off. Still the blue screen didn't stay, because the system rebooted automatically. Do you have any idea why this is happening?

At least I have observed something. I had an older external hard drive connected where I'm saving my images (there is also a back-up Drobo) when the system crashed. I remembered that during the last two crashes the same hard drive was connected, too. It is an older Western Digital USB pocket drive. Maybe this is the source for the crashes. Since I don't use it often it might be the explanation for the irregular cashes. I still could be something else, but it is a promising idea to follow up.

I'm planning to copy the content to a new hard drive tomorrow and the keep working with the new one to see if the crash happens again. If I have time later this week I can try to connect the old drive with driver verification turned on in case the crash doesn't show up. Maybe I can than reproduce the crash.

Cheers Marcus

Hi Marcus,

MEMORY.DMP (kernel, etc) are stored in the Windows directory, not Minidump.

It could be that the older hard drive is causing the crashes, yes. I'd uninstall it from the system entirely for troubleshooting purposes.

Regards,

Patrick