Bugcheck 139 Random Crashes Server 2012

That is almost impossible to tell, just because a module was loaded at the time of the crash, it doesn't mean it is the culprit.
As Patrick has said, a Complete Memory Dump with DV enabled would be very helpful in tracking down the culprit.
It's almost always necessary for such configurations when dealing with 0x139s, especially list corruption, it could have occurred long before the crash, leaving the grasp of a minidump's capabilities.
 
Okay, so I found the printer drivers:

Code: 
Unloaded modules:
fffff801`e3840000 fffff801`e384d000   usbprint.sys
fffff801`e384d000 fffff801`e3856000   hppdfaxio.sys
fffff801`e3856000 fffff801`e385f000   hppdbulkio.sys
fffff801`e3081000 fffff801`e308e000   usbprint.sys
fffff801`e33f6000 fffff801`e33ff000   hppdfaxio.sys
fffff801`e31e8000 fffff801`e31f1000   hppdbulkio.sys
fffff801`e3800000 fffff801`e3826000   USBSTOR.SYS
fffff801`e3826000 fffff801`e3840000   EhStorClass.sys
fffff801`e39a1000 fffff801`e39c7000   USBSTOR.SYS
fffff801`e39c7000 fffff801`e39e1000   EhStorClass.sys
fffff801`e3840000 fffff801`e3866000   USBSTOR.SYS
fffff801`e3866000 fffff801`e3880000   EhStorClass.sys
fffff801`e3800000 fffff801`e3826000   USBSTOR.SYS
fffff801`e3826000 fffff801`e3840000   EhStorClass.sys
fffff801`e39a1000 fffff801`e39c7000   USBSTOR.SYS
fffff801`e39c7000 fffff801`e39e1000   EhStorClass.sys
fffff801`e385a000 fffff801`e3880000   USBSTOR.SYS
fffff801`e3880000 fffff801`e389a000   EhStorClass.sys
fffff801`e381a000 fffff801`e3840000   USBSTOR.SYS
fffff801`e3840000 fffff801`e385a000   EhStorClass.sys
fffff801`e39c7000 fffff801`e39ed000   USBSTOR.SYS
fffff801`e3800000 fffff801`e381a000   EhStorClass.sys
fffff801`e39a1000 fffff801`e39c7000   USBSTOR.SYS
fffff801`e1f98000 fffff801`e1fb2000   EhStorClass.sys
fffff801`e3abc000 fffff801`e4090000   iqvw64e.sys
fffff801`e395b000 fffff801`e3968000   mst.sys 
fffff801`e249a000 fffff801`e24a6000   dump_storport.sys
fffff801`e2077000 fffff801`e2088000   dump_percsas2.sys
fffff801`e2088000 fffff801`e209e000   dump_dumpfve.sys
fffff801`e1bbc000 fffff801`e1bc5000   avgboota.sys
fffff801`e249a000 fffff801`e24a6000   hwpolicy.sys
fffff801`e1bc5000 fffff801`e1be0000   sacdrv.sys

IDK why they're unloaded here, as in the other kernel dump (you provided two), they're loaded. Possibly a driver bug? Maybe a printer issue? Maybe nothing at all? Hard to say.

Also I checked the raw stack of both dumps, and both are essentially the same.

Code: 
2: kd> !thread
THREAD ffffe0011523a080  Cid 1730.114c  Teb: 00007ff71d635000 Win32Thread: fffff90140e7e010 RUNNING on processor 2
Not impersonating
DeviceMap                 ffffc0001269bee0
Owning Process            ffffe0011432b900       Image:         explorer.exe
Attached Process          N/A            Image:         N/A
Wait Start TickCount      12009603       Ticks: 0
Context Switch Count      28809          IdealProcessor: 2             
UserTime                  00:00:00.250
KernelTime                00:00:00.671
Win32 Start Address 0x00007ff985e1a1f0
Stack Init ffffd000212dafd0 Current ffffd000212da9f0
Base ffffd000212db000 Limit ffffd000212d5000 Call 0

Code: 
2: kd> dps ffffd000212d5000 ffffd000212db000
//Trimmed of course
ffffd000`212d8e18  fffff800`dec66d76 MxG2rDO64+0x2d76
ffffd000`212d91b8  fffff800`deff006c dump_percsas2+0x806c

Two drivers working and being called throughout the raw stack, specifically the Matrox G200eR driver and the MEGASAS RAID Controller Driver by the LSI Corp (found in Dell storage drivers also).

Code: 
2: kd> lmvm percsas2
start             end                 module name
fffff800`dda8f000 fffff800`ddaa0000   percsas2   (deferred)             
    Image path: \SystemRoot\System32\drivers\percsas2.sys
    Image name: percsas2.sys
    Timestamp:        Thu Dec 05 15:47:44 2013

Here's my theory - I don't think the unloaded printer drivers from HP or printer drivers from HP in general are causing the issue. Is it possible? Sure. If you think so, go ahead and either update (if available) or remove it from the equation entirely if possible. I know it's a corporate environment, so it may not be. If it comes down to this actually being the problem, you'll need to work it out with HP.

I instead think that AVG is playing a role in the crashes by conflicting with the RAID controller drivers. I personally wouldn't install AVG in a corporate environment (or business) if you paid me to. Is it possible to remove and replace AVG entirely for now?

Bottom line, the raw stack isn't indicative of anything. It's just a series of calls that can be completely normal and not mean anything. It's an 0x139 bug check though, so we're either digging at the bottom of the barrel and hoping our guesses are correct, or we wait for a verifier crash dump.
 
Hi there.

I removed AVG back at the beginning of October when all of this happened.

Basically, there were no issues, then around the time of the Microsoft Updates in September all this started to happen. I updated all the DELL stuff, then it was OK for a few weeks, and crashed once again. (The October crash.) After that I uninstalled AVG, Bitlocker, and basically everything else I could to get in back down to a vanilla system. After 8 weeks I thought I was OK, then the 7 crashes at the end of December. (I also find it strange it crashed almost on the same days in both September and December.)

What date file are you seeing AVG in? If it is from the December crashes perhaps it is still lingering around even after I uninstalled it.

The HP driver is from 2010, but it is the latest driver, provided by Microsoft. i thought we had it with that, because apparently the server does like to crash when people print, but obviously they print all the time and no crash.
 
BTW: I think I realize what you mean about bandwidth. There is 8GB of RAM in this server, so the complete dump file would be 8GB which would be hard to get to you, right?

Though OneDrive allows 10GB I think.

Do you still want a complete dump file?
 
What date file are you seeing AVG in? If it is from the December crashes perhaps it is still lingering around even after I uninstalled it.
Click to expand...

I can't seem to get Onedrive to let me download the kernel-dumps again, so whatever date those were generated, AVG was installed/loaded. If that was recent (which I think it was), use the removal tool - http://www.avg.com/us-en/utilities

What server product do *you* recommend?
Click to expand...

For business/corporate environments, it generally comes down to three that I recommend:

Symantec Endpoint Protection
Webroot SecureAnywhere Endpoint Protection
Sophos Endpoint Protection w/ Enterprise Console

BTW: I think I realize what you mean about bandwidth. There is 8GB of RAM in this server, so the complete dump file would be 8GB which would be hard to get to you, right?
Click to expand...

Bandwidth as in would you have the resources (network wise) to get an 8GB crash dump (but zipped) uploaded to the internet for me to download? If so, yes I would like it.
 
Okay, so AVG isn't loaded in that dump. I also just noticed that the prior dumps are properly named (as far as their dates go) on OneDrive, so now I can see that I was looking at a crash dump from September. With that said, AVG certainly has nothing do with the crashes because it doesn't exist anymore. However, now I can definitely see the printer drivers being the next culprit. They're so old, and that's probably what it is.

Code: 
5: kd> lmvm hppdbulkio
start             end                 module name
fffff800`e8678000 fffff800`e8681000   hppdbulkio   (deferred)             
    Image path: \SystemRoot\system32\drivers\hppdbulkio.sys
    Image name: hppdbulkio.sys
    Timestamp:        Tue Apr 29 12:00:07 2008

Code: 
5: kd> vertarget
Windows 8 Kernel Version 9600 MP (8 procs) Free x64
Product: Server, suite: TerminalServer SingleUserTS
Built by: 9600.17328.amd64fre.winblue_r3.140827-1500
Machine Name:
Kernel base = 0xfffff800`9941c000 PsLoadedModuleList = 0xfffff800`996f2370
Debug session time: Wed Dec 31 08:35:29.535 2014 (UTC - 5:00)
System Uptime: 1 days 19:03:20.103

2008 printer drivers running on a Win8 server, ouch. No update available for the printer? If not, I think it may be time to remove it from the equation + the printer software for now for testing.
 
Yes, those are the most "updated" versions. The driver itself is from 2010, which I understand is still not good. I was a little surprised at that myself. And those are directly from Microsoft.

I hate to have the client replace a $1,000 printer only to have this happen again. That's why I was very hesitant to suggest that until I was 100% sure.

If we enable driver verifier, and it is this printer driver, are the odds we'd see a crash and be able to say with moderate certainty that the printer driver is causing the issue?
 
If we enable driver verifier, and it is this printer driver, are the odds we'd see a crash and be able to say with moderate certainty that the printer driver is causing the issue?
Click to expand...

More than moderate, yes.
 
LOL. OK.

Alright, I am going to roll the dice for now. Though the next crash, I'll enable the verifier and we'll find the culprit.

I still don't get how a network of 15 users can use the same system for 8 weeks with no problem, and then in the next week it crashes a few times. Just so weird.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top