New
#1
New BSOD
Could someone please look at this dmp file for me??
Attachment 307615
Tom,
I'me having a real problem even reading the debug file - I can't even see which drivers were loaded. Is your Windows 8 updated? I'll have to get Arc to look at this.
Code:************* Symbol Loading Error Summary ************** Module name Error ntoskrnl The system cannot find the file specified You can troubleshoot most symbol related issues by turning on symbol loading diagnostics (!sym noisy) and repeating the command that caused symbols to be loaded. You should also verify that your symbol search path (.sympath) is correct. ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 139, {3, ffffd000204cd810, ffffd000204cd768, 0} ***** Kernel symbols are WRONG. Please fix symbols to do analysis ************************************************************************* *** *** *** *** *** Either you specified an unqualified symbol, or your debugger *** *** doesn't have full symbol information. Unqualified symbol *** *** resolution is turned off by default. Please either specify a *** *** fully qualified symbol module!symbolname, or enable resolution *** *** of unqualified symbols by typing ".symopt- 100". Note that *** *** enabling unqualified symbol resolution with network symbol *** *** server shares in the symbol path may cause the debugger to *** *** appear to hang for long periods of time when an incorrect *** *** symbol name is typed or the network symbol server is down. *** *** *** *** For some commands to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: nt!_KPRCB *** *** *** ************************************************************************* Probably caused by : win32k.sys ( win32k+14719b ) Followup: MachineOwner --------- 2: kd> !thread GetPointerFromAddress: unable to read from fffff80224ddb000 ************************************************************************* *** *** *** *** *** Either you specified an unqualified symbol, or your debugger *** *** doesn't have full symbol information. Unqualified symbol *** *** resolution is turned off by default. Please either specify a *** *** fully qualified symbol module!symbolname, or enable resolution *** *** of unqualified symbols by typing ".symopt- 100". Note that *** *** enabling unqualified symbol resolution with network symbol *** *** server shares in the symbol path may cause the debugger to *** *** appear to hang for long periods of time when an incorrect *** *** symbol name is typed or the network symbol server is down. *** *** *** *** For some commands to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: nt!_ETHREAD *** *** *** ************************************************************************* ffffe0008bdaf400: Unable to get thread contents
Yes,
win 8.1.1 is up to date. I've never seen a 139 bug check before. Hopefully Arc can make heads or tails out of this....
Have you installed any 3rd party software recently?
http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx
Maybe try Driver Verifier?
Give Driver Verifier a go Tom.
Standard canned speech:
Please do the following:
Run Driver Verifier for 24 hours or the occurrence of the next crash, whichever is earlier.
Driver Verifier - Enable and Disable
Driver Verifier will cause your computer to run very sluggishly - this is normal. What it is trying to do is force your system to BSOD and isolate the offending driver/s. When it does, reboot, disable driver verifier, reboot as normal and upload the new dmp file/s here.
I recommend creating a system restore point before turning on driver verifier:
System Restore Point - Create
If your system fails to boot to desktop once driver verifier is enabled, turn it off by booting into Safe Mode:
Safe Mode
Hi Tom. :)
I checked the data when you posted he thread, and got the same result as Cloin and Derek got. Symbol error. As far as I have faced, symbol error occurs in two different situations:
- When the symbol server is down.
- When some third party drivers blocks access to their symbol. The private symbols.
As you said it already, a stop 0x139 is not very common one. Plus we cannot identify anything form the crash dump. Still, the exception code here is:
As there is a common probability of the issue being a private symbol and is caused by stack overflow, it may be expected that the Driver Verifier will bring something there.Code:ExceptionCode: c0000409 (Security check failure or stack buffer overrun)
At the same time, you may consider WDO to run a scan; as the bugcheck code says about some security check failure.
Best wishes. :)