Bugcheck 139 Random Crashes Server 2012

YardleyBill

Member
Joined
Jan 4, 2015
Posts
17
I installed a DELL server with Server 2012 R2 in a client location in April 2014. It was humming along nicely with no issues until September of this year, when it started getting the KERNEL BUGCHECK 139 errors.

I have done just about everything. All drivers from DELL are at their latest date (at least from DELL). (I've been working with DELL on the issue.) I have uninstalled all 3rd party programs that are not critical. (No antivirus, etc.)

It crashed around 5 times at the end of September, then I made some changes. Then it crashed once (I think) in October, after which I went totally vanilla. I thought things were fixed, but we've had about 6 crashes in the past 10 days.

I am hoping someone here can look at these crash files and shed some light on what to try next. I'm really at the end of my rope.

I have not run driver verifier yet as this is a production server.

HELP!!!! :banghead:
 
After finding this forum I figured you guys would have this solved in minutes!!!!

Usually we do, but if everyone else like me didn't even see this thread, then maybe that's why it slipped under the radar.

KERNEL_SECURITY_CHECK_FAILURE (139)

This bug check indicates that the kernel has detected the corruption of a critical data structure.

Code:
5: kd> .bugcheck
Bugcheck code 00000139
Arguments 00000000`00000003 ffffd001`131d97a0 ffffd001`131d96f8 00000000`00000000

- The first argument is 3 which indicates a LIST_ENTRY was corrupted.

Code:
5: kd> .exr ffffd001`131d96f8
ExceptionAddress: fffff960001df9ff (win32k!SURFACE::RemoveLSurf+0x000000000000006b)
   ExceptionCode: c0000409 (Security check failure or stack buffer overrun)
  ExceptionFlags: 00000001
NumberParameters: 1
   Parameter[0]: 0000000000000003

Taking a look at the 3rd argument, we can see the exception that caused Windows to throw the bug check was either a security check failure or a stack buffer overrun. Given this is a small memory dump, we can't see what in kernel memory caused the buffer overflow, which in turn raised the exception. With that said, we cannot do any further debugging really. We'll need a verifier enabled kernel-dump to go further.


Driver Verifier:

What is Driver Verifier?

Driver Verifier monitors Windows kernel-mode drivers, graphics drivers, and even 3rd party drivers to detect illegal function calls or actions that might corrupt the system. Driver Verifier can subject the Windows drivers to a variety of stresses and tests to find improper behavior.

Essentially, if there's a 3rd party driver believed to be causing the issues at hand, enabling Driver Verifier will help us see which specific driver is causing the problem.

Before enabling Driver Verifier, it is recommended to create a System Restore Point:

Vista - START | type rstrui - create a restore point
Windows 7 - START | type create | select "Create a Restore Point"
Windows 8/8.1 - Restore Point - Create in Windows 8

How to enable Driver Verifier:

Start > type "verifier" without the quotes > Select the following options -

1. Select - "Create custom settings (for code developers)"
2. Select - "Select individual settings from a full list"
3. Check the following boxes -
- Special Pool
- Pool Tracking
- Force IRQL Checking
- Deadlock Detection
- Security Checks (only on Windows 7 & 8/8.1)
- DDI compliance checking (only on Windows 8/8.1)
- Miscellaneous Checks
4. Select - "Select driver names from a list"
5. Click on the "Provider" tab. This will sort all of the drivers by the provider.
6. Check EVERY box that is NOT provided by Microsoft / Microsoft Corporation.
7. Click on Finish.
8. Restart.

Important information regarding Driver Verifier:

- Perhaps the most important which I will now clarify as this has been misunderstood often, enabling Driver Verifier by itself is not! a solution, but instead a diagnostic utility. It will tell us if a driver is causing your issues, but again it will not outright solve your issues.

- If Driver Verifier finds a violation, the system will BSOD. To expand on this a bit more for the interested, specifically what Driver Verifier actually does is it looks for any driver making illegal function calls, causing memory leaks, etc. When and/if this happens, system corruption occurs if allowed to continue. When Driver Verifier is enabled per my instructions above, it is monitoring all 3rd party drivers (as we have it set that way) and when it catches a driver attempting to do this, it will quickly flag that driver as being a troublemaker, and bring down the system safely before any corruption can occur.

- After enabling Driver Verifier and restarting the system, depending on the culprit, if for example the driver is on start-up, you may not be able to get back into normal Windows because Driver Verifier will detect it in violation almost straight away, and as stated above, that will cause / force a BSOD.

If this happens, do not panic, do the following:

- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.

- Once in Safe Mode - Start > Search > type "cmd" without the quotes.

- To turn off Driver Verifier, type in cmd "verifier /reset" without the quotes.

- Restart and boot into normal Windows.

If your OS became corrupt or you cannot boot into Windows after disabling verifier via Safe Mode:

- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.

- Once in Safe Mode - Start > type "system restore" without the quotes.

- Choose the restore point you created earlier.

-- Note that Safe Mode for Windows 8/8.1 is a bit different, and you may need to try different methods: 5 Ways to Boot into Safe Mode in Windows 8 & Windows 8.1

How long should I keep Driver Verifier enabled for?

I recommend keeping it enabled for at least 24 hours. If you don't BSOD by then, disable Driver Verifier. I will usually say whether or not I'd like for you to keep it enabled any longer.

My system BSOD'd with Driver Verifier enabled, where can I find the crash dumps?

- If you have the system set to generate Small Memory Dumps, they will be located in %systemroot%\Minidump.

- If you have the system set to generate Kernel Memory Dumps, it will be located in %systemroot% and labeled MEMORY.DMP.

Any other questions can most likely be answered by this article:

Using Driver Verifier to identify issues with Windows drivers for advanced users



After the system crashes with verifier enabled, upload the MEMORY.DMP file located in C:\Windows to a hosting site of your choice, preferably one without ads, and then link it here.
 
Couple of thoughts/questions...

Not really knowing a whole lot about this level of crash file analysis, I've made a hypothesis that it is the video driver. These questions will help me learn more.

1. I've noticed that in every DMP file, the process_name that is listed is DWM.EXE. Since this is obviously graphics oriented, it makes me thinks it is a video issue. Is the process listed in the DMP related to the crash, or not necessarily related?

2. When I look at the list of the things on the stack right before the blue screen is called, they seem like video related things to me. Would you agree or disagree?
win32k!SURFACE::RemoveLSurf+0x6b
win32k!SFMLOGICALSURFACE::SetShape+0x51
win32k!SFMLOGICALSURFACE::DeInitialize+0x4b
win32k!bhLSurfDestroyLogicalSurfaceObject+0x78
 
The guesses you're making may end up being correct, but they could be wrong.

The reason DWM is the crashing processes at the time of the bug check is because as you noted, there's a lot of win32k GUI stuff in the stack. With a full dump we'll really be able to see what's going on before that, even into before kernel-mode.

P.S. I have a full MEMORY.DMP ... would that help?

Yes.
 
Actually, if your network/bandwidth permits it, a verifier enabled complete memory dump in this case would be the bees knees as I can see what's going on in user-mode before stuff hits the fan.
 
OK, will do.

The thing that is odd, is that is seems to crash a lot, like 5 times in 10 days. And then it goes 6 weeks without any crashes. Wouldn't you think it would crash more often?

It's so frustrating...
 
Like I said, it depends entirely on what's causing the crashes. If it's a driver bug that's only occurring in certain calls or a certain IRQL transition for example, then that's why. If it's a hardware problem for example RAM and only occurs whenever it feels like occurring depending on the fault, then that's why. Until I see a verifier enabled crash dump, it's all guesses.
 
It is a production server I do not have physical access to.

If it crashes again, I will enable driver verfier.

BTW: when it bluescreens while running verifier, will it reboot?

I figure I can run it one day they are closed, and just be ready to go in if it doesn't reboot upon initially setting it up.
 
BTW: when it bluescreens while running verifier, will it reboot?

Yes, it will. It'll crash like normal.

I figure I can run it one day they are closed, and just be ready to go in if it doesn't reboot upon initially setting it up.

Good idea.
 
One more "educational" question...

DELL had said it was the printer driver because they said the HP driver was unloaded a lot right before the crash. Do unloaded modules have any bearing on this sort of crash, or no? Or is that another thing that cannot be ascertained without said verifier dump?
 
If you'd like my opinion, I have absolutely no idea how Dell could have gathered an unloaded printer driver caused an 0x139 bug check from a small memory dump with no stack.
 
Actually, I forgot you provided non-verifier kernel dumps. Let me check the raw stack there and see if that's where they are getting that from. BRB.
 

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

Back
Top