New
#21
I don't know about the previous stuff but all of that was caused by something called esl wire.
I don't know about the previous stuff but all of that was caused by something called esl wire.
All three new ones read this same exact thing, or something close.Code:******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* KMODE_EXCEPTION_NOT_HANDLED (1e) This is a very common bugcheck. Usually the exception address pinpoints the driver/function that caused the problem. Always note this address as well as the link date of the driver/image that contains this address. Arguments: Arg1: ffffffffc0000005, The exception code that was not handled Arg2: fffff80002e8f356, The address that the exception occurred at Arg3: 0000000000000000, Parameter 0 of the exception Arg4: 0000000000000000, Parameter 1 of the exception Debugging Details: ------------------ EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. FAULTING_IP: nt!RtlCaptureContext+86 fffff800`02e8f356 0f2981a0010000 movaps xmmword ptr [rcx+1A0h],xmm0 EXCEPTION_PARAMETER1: 0000000000000000 EXCEPTION_PARAMETER2: 0000000000000000 READ_ADDRESS: GetPointerFromAddress: unable to read from fffff800030c1100 0000000000000000 CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: VERIFIER_ENABLED_VISTA_MINIDUMP BUGCHECK_STR: 0x1E PROCESS_NAME: System CURRENT_IRQL: 0 LAST_CONTROL_TRANSFER: from fffff80002eda588 to fffff80002e8ec40 STACK_TEXT: fffff880`03383bf8 fffff800`02eda588 : 00000000`0000001e ffffffff`c0000005 fffff800`02e8f356 00000000`00000000 : nt!KeBugCheckEx fffff880`03383c00 fffff800`02e8e2c2 : fffff880`033843d8 00000000`00000000 fffff880`03384480 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x4977d fffff880`033842a0 fffff800`02e8cbca : fffff800`03091000 fffff880`03384500 fffff880`03384830 00000000`80000000 : nt!KiExceptionDispatch+0xc2 fffff880`03384480 fffff800`02e8f356 : 00000000`00000202 fffff800`02f4a1f3 fffff880`03380000 fffff880`03386000 : nt!KiGeneralProtectionFault+0x10a fffff880`03384618 fffff800`02f4a1f3 : fffff880`03380000 fffff880`03386000 fffff880`00000003 00000000`80000000 : nt!RtlCaptureContext+0x86 fffff880`03384628 fffff800`02f4b803 : fffffa80`06d2c598 fffff880`00000011 fffff980`00000000 fffff800`00000004 : nt!RtlpWalkFrameChain+0xa3 fffff880`03384cc8 fffff800`02f4c68b : 00000000`00000003 fffffa80`06d2c598 00000000`00000000 00000000`00000000 : nt!RtlWalkFrameChain+0x63 fffff880`03384cf8 fffff800`0332502c : fffffa80`06d2c580 00000000`00000470 00000000`000000c0 00000000`00000468 : nt!RtlCaptureStackBackTrace+0x4b fffff880`03384d28 fffff800`0332709a : fffff880`03380000 fffff880`03386000 00000000`000000c0 00000000`00000470 : nt!ViPoolLogStackCallout+0x1c fffff880`03384d58 fffff800`03329cc6 : fffffa80`09f49fe0 fffff980`030a4b90 fffffa80`09f47c00 00000000`00000000 : nt!ViPoolLogStackTrace+0x8a fffff880`03384d88 fffff800`03329e81 : 00000000`00000468 fffff880`0902f000 fffff880`6c644d56 00000000`00000086 : nt!VeAllocatePoolWithTagPriority+0x2b6 fffff880`03384df8 fffff880`090d588b : 00000000`0002773f fffff880`03384f90 fffff880`090d46e2 fffff880`090d4673 : nt!VerifierIoAllocateMdl+0x71 fffff880`03384e58 00000000`0002773f : fffff880`03384f90 fffff880`090d46e2 fffff880`090d4673 00000000`00000000 : ESLWireACD+0xa688b fffff880`03384e60 fffff880`03384f90 : fffff880`090d46e2 fffff880`090d4673 00000000`00000000 00000000`00000000 : 0x2773f fffff880`03384e68 fffff880`090d46e2 : fffff880`090d4673 00000000`00000000 00000000`00000000 fffff880`0901f000 : 0xfffff880`03384f90 fffff880`03384e70 fffff880`090d4673 : 00000000`00000000 00000000`00000000 fffff880`0901f000 fffffa80`09f48000 : ESLWireACD+0xa56e2 fffff880`03384e78 00000000`00000000 : 00000000`00000000 fffff880`0901f000 fffffa80`09f48000 fffff880`033857c0 : ESLWireACD+0xa5673 STACK_COMMAND: kb FOLLOWUP_IP: ESLWireACD+a688b fffff880`090d588b ?? ??? SYMBOL_STACK_INDEX: c SYMBOL_NAME: ESLWireACD+a688b FOLLOWUP_NAME: MachineOwner MODULE_NAME: ESLWireACD IMAGE_NAME: ESLWireACD.sys DEBUG_FLR_IMAGE_TIMESTAMP: 4ea7eb9a FAILURE_BUCKET_ID: X64_0x1E_VRF_ESLWireACD+a688b BUCKET_ID: X64_0x1E_VRF_ESLWireACD+a688b Followup: MachineOwner
Ye thats right, esl wire is anti cheat sofware that i have to use when im in cs:s & mw3 league's.
is esl wire becouse of those bsod or ? :S
Hi all, my first post here, i seem to be having almost the same exact problems. Should i start new topic or use this one? Im not home right now, but when i get there in couple hours i can post dumpfiles etc. I have been getting these blue screens for about a week and also cant update windows, but i never have used this esl wire, but some other anticheats before format. Sorry for the poor english
I leaved my computer running while i was outside for 30 minutes and when i came back i have had bluescreen :S, nothing was running other that my system tray, heres that minidump.
Attachment 199538
i can see that all my bluescreens have Crash address: ntoskrnl.exe+#####
and all my newest one and the driver verified bsod have coused by driver: fltmgr.sys
I am a big fan of Nir Sofer's work, BUT blueScreenView more often than not, doesn't point out the correct causes. Similarly Who crashed is even worse.
I prefer to use WinDbg (the Windows Debugging Tools) to read the memory dumps. It is the Gold standard for those of us that do this and often will give us the answer by itself. (we don't need the full jcgriff2 report each time).
This crash was not driver verified and was caused by a driver passing bad information.
ah ok, ye i didnt had the verified on, i was waiting for answer if to uninstall esl wire and test driver verified again, you think i should do that or ?,
Uninstalled esl wire, reboot, after 30 minutes or so bluesscreen -.-
Attachment 199586