0x00000139 BSOD (Have Dmp Files)

[pheonixburned]

Reinstalled Win 8, still having BSOD's


https://onedrive.live.com/embed?cid=DF7F5B12C8E44F56&resid=DF7F5B12C8E44F56%212340&authkey=AMQQjXf75PCsSEY

What Might be the cause here?

 

[johnbl]

overall, looks like there are no actual useful machine updates for your BIOS or drivers.
the bugcheck was in the filesystem, and you have a special anti cheat software installed and it might have a problem.

all i could suggest it go into control panel services and turn off any of the nvidia software your don't actually use.
most of the nvidia services have NV in the name. you can change the startup type from auto to manual.

your system even ran for 10 and half hours so this problem might be hard to find.
you should change your memory dump type to full or kernel and reboot so your debug info will not be removed from the memory dump. You should also run cmd.exe as an admin then run verifier.exe /standard /all
to set the debug flags, then run until you bugcheck again.
you turn off the debug flags by running
verifier.exe /reset

Basically with this older manchine and no real vendor support your only hope is a bug in the anticheat software because you can get a update for that.

I would also run a malwarebyes scan and a virus scan in case you have something infecting your filesystem.
(again i think it is going to be your anticheat software making a mistake)

--------------

something overflowed the stack in the filesystem, the system thought it could be a malware attack and shutdown.

the running process was nvSCPAPISvr.exe NVIDIA Stereoscopic 3D Driver. It could just be a victim of some other problem but if you don't use it I would stop the service.

here is the error code:
ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.

you have a couple of suspect drivers:
C:\Program Files (x86)\Common Files\BattlEye\BEDaisy.sys Wed Feb 18 06:22:31 2015
(it is a game anticheat driver that is very new and just might have a bug, most likely suspect)

\SystemRoot\System32\drivers\uliagpkx.sys Thu Aug 22 04:39:38 2013
driver for ULi AGPv3.0 Filter for K8/9 Processor Platform

machine info:
BIOS Version 080015
BIOS Release Date 08/11/2010
Manufacturer ECS
Product Name A885GM-A2
Version 1.0
Processor Version AMD Phenom(tm) II X6 1100T Processor
Processor Voltage 8fh - 1.5V
External Clock 200MHz
Max Speed 3700MHz
Current Speed 3300MHz

 

[pheonixburned]

Had it crash and took the verifier.exe /reset step

https://onedrive.live.com/embed?cid=DF7F5B12C8E44F56&resid=DF7F5B12C8E44F56%212341&authkey=AB_QlmnGUbOp-AA

 

[johnbl]

bug in battleye service and driver, you will have to get a updated version from them.

-------
this bugcheck shows that verifier did catch the game anticheat software messing up.

basicaly, BEService.exe passed a usermode handle to its companion driver
\C:\Program Files (x86)\Common Files\BattlEye\BEDaisy.sys
that driver then used it as a kernel mode handle and corrupted the stack.

generally, this should not be done but would mostly work if the driver locks down the memory at each call.
Problem, the systems memory manager is free to move the memory around if it needs to for some reason and the driver will bugcheck if it used the old memory address (the address my have another drivers data)

this is a bug in the design of battleye software.
it looks like your system was up for 11 mins and 30 seconds before verifier caught the bug.

here is the debug info:

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
Arguments:
Arg1: 00000000000000e2, IRP field is a user-mode address but Irp->RequestorMode is KernelMode.
Arg2: ffffcf80c0b2e790, IRP address.
Arg3: 00000000010b3040, User-mode address present as the value of an IRP field.
Arg4: 0000000000000000

 

[pheonixburned]

Update:

Went ahead and updated battleye. According to their website, memory faults could be the same listings we came to the conclusion of, such as virus' or trojans, even bad memory. I have neither of those. I moved on to a section talking about crashes and it said windows has a bugged update which may have adverse effects on Battle Eye. I Uninstalled the update and i'm waiting to see what the status is now. I'll keep the verifier on.

Thanks Much, John.

 

[johnbl]

the problem that windows verifier caught in the debugger is not a bug in windows, it is a common bug in 3rd party drivers.
They were passing a user mode handle to a kernel mode routine. This is a design flaw in their code. Sure it will work most of the time as long as the window memory manager does not page your user mode app and page it back in at another location. The more memory you have and the fewer programs you have running, the longer it will work. Conversely, limit the memory and force paging should bugcheck the system if verifier is on or corrupt system memory if it is turned off. The corruption will result in random driver crashed. You may find that you can stop the service and just start it when you need it to avoid the corruption.

Update:

Went ahead and updated battleye. According to their website, memory faults could be the same listings we came to the conclusion of, such as virus' or trojans, even bad memory. I have neither of those. I moved on to a section talking about crashes and it said windows has a bugged update which may have adverse effects on Battle Eye. I Uninstalled the update and i'm waiting to see what the status is now. I'll keep the verifier on.

Thanks Much, John.