A VM that is running Windows 2008 R2 has experienced a BSOD. The application owner notified me and sent me some useful information.
Problem signature:
Problem Event Name: BlueScreen
OS Version: 6.1.7601.2.1.0.400.8
Locale ID: 1033
Additional information about the problem:
BCCode: 24
BCP1: 00000000001904FB
BCP2: FFFFF88006C34E28
BCP3: FFFFF88006C34680
BCP4: FFFFF880014E81B2
OS Version: 6_1_7601
Service Pack: 1_0
Product: 400_3
Files that help describe the problem:
C:\Windows\Minidump50415-20202-01.dmp
C:\Users\servername\AppData\Local\Temp\WER-42663418-0.sysdata.xml
Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409
If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt
Good info here, but with all BSODs, you should look at the dump file for more definitive information.
I grabbed the dump file, and downloaded Windows SDK. During the install, I unchecked all the boxes except the Debugging Tools for Windows and installed.
Launch WinDGB (x64) as administrator. The first step is to configure the symbol file path. It can be any folder on your server, just create an empty one and go to File > Symbol File Path.
In the symbol search path, I entered the following and clicked OK.
SRV*c:\tmp\symbols*http://msdl.microsoft.com/download/symbols
Save the workspace. File > Save Workspace
Opened the dump file. File > Open Crash Dump.
Before you proceed, read the info under the bugcheck analysis. It tells you what probably caused the error.
NTFS.sys
Click the link in the Bugcheck Analysis section, !analyze -y to get more information.
Read through the info. Note the following:
- Process Name
- Bugcheck_str
- Image Name
- Area right above the debugging details
At the very top you’ll see a message and some arguments.
At the kd> prompt at the bottom of the debugger, enter
.bugcheck
In the analysis you see the Arguments. Do a .cxr on the 3rd argument as it suggests.
.cxr fffff88004523680
Next,
Run the kb command for a more informative stack trace.
There are now a few pieces of information to hone in on.
- The bug check code
- The stack track text
Look up the bugcheck code here on the msdn bug check code reference page.
https://msdn.microsoft.com/en-us/library/windows/hardware/hh994433%28v=vs.85%29.aspx
Google the stack trace text and this vmware KB article # 2115997 comes up.
This appears to be a known issue with a few versions of vmware tools:
I looked in the vmware.log file for the entries mentioned and they matched.
The image name on the dump file referenced vds.exe and this VM is running tools version 9.4.11. This issue only appeared since the tools upgrade when we upgraded to 5.5 Patch 4
To confirm what version of tools you’re running, go to the VM and in the notifications bar, right click on the icon and select About VMware Tools
Time to downgrade tools.
Find the tools ISO that will have a version that is not listed in the KB, but one that is compatible with your version of vsphere.
https://packages.vmware.com/tools/versions
Search for your current version and find the one closest to it that is not affected with this issue.
You’ll have to uninstall the current version of tools before installing older version. It will require a reboot.
The hardware version will not be an issue with this versions of tools, but confirm that for your specific environment.
1 Comment on BSOD on a Windows VM bugcheck code 24
Leave a Reply
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Thank You. This is by far the most thoughtful and original suggestion I’ve seen regarding BCCode: 24 BCP1: 00000000001904FB that I’ve found after several hours of looking. You provided a broadly useful method that is not just limited to VMware or virtual machines.
Most of the other information I’ve seen amount to a rehash of wastebasket diagnoses for the problem (e.g. HDD error or virus)or a request to upload a bunch of information that results the same amateurish guess or in more requests to upload info and finally a wild guess.
I’ve been looking specifically for what the 1904FB means; from this, my guess is it’s where the NTFS code fields OS-thrown exceptions that occur while it is in control. Of course, it would have helped if MS had included a few more morsels of info in the BC summary, like maybe the exception code.
Despite my railing against the prevalence of cursory suggestions, I do think it would probably be wise to run a virus scan, SFC and a CHKDSK first, since those are so easy to do, despite the unlikelihood that they will find anything.