[SOLVED] BSOD 0x7f UPEXPECTED_KERNEL_TRAP_MODE caused by ntoskrnl.exe - Windows 8.1 x64

E

error01671

New member
Joined
Jun 5, 2015
Posts
4
Hi! I'm using ASUS X552MD laptop with Windows 8.1, I just removed my DVD-ROM drive and added a SSD a month ago.

But recently this BSOD came out, I thought it would be just some drivers were outdated, so I updated them but no help.

Specs:
ASUS X552MD laptop
Intel Pentium N3530
NVIDIA 820M
500G HDD and 128G SSD
Windows 8.1 x64

Can't run PERFMON System Health Report, I don't know.
 

Attachments

Re: BSOD 0x7f UPEXPECTED_KERNEL_TRAP_MODE caused by ntoskrnl.exe Windows 8.1 x64

Code: 
0: kd> .dumpdebug
----- 64 bit Kernel Mini Dump Analysis

DUMP_HEADER64:
MajorVersion        0000000f
MinorVersion        00002580
KdSecondaryVersion  00000000
DirectoryTableBase  00000000`001ab000
PfnDataBase         fffff800`523670f0
PsLoadedModuleList  fffff800`522dd850
PsActiveProcessHead fffff800`522c3580
MachineImageType    00008664
NumberProcessors    00000004
BugCheckCode        0000007f
BugCheckParameter1  00000000`00000008
BugCheckParameter2  fffff800`53a37e70
BugCheckParameter3  ffffd000`25695fd0
BugCheckParameter4  fffff800`52076663
KdDebuggerDataBlock fffff800`522aa530
ProductType         00000001
SuiteMask           00000310
WriterStatus        00000000
MiniDumpFields      00000cff 

0: kd> k
Child-SP          RetAddr           Call Site
fffff800`53a37d28 fffff800`521607e9 nt!KeBugCheckEx
fffff800`53a37d30 fffff800`5215e8f4 nt!KiBugCheckDispatch+0x69
fffff800`53a37e70 fffff800`52076663 nt!KiDoubleFaultAbort+0xb4
ffffd000`25695fd0 ffffe001`13724a22 nt!KeExpandKernelStackAndCalloutInternal+0x53
ffffd000`256960c0 ffffe001`13724950 em008_64+0x45a22
ffffd000`256960c8 ffffd000`256960f0 em008_64+0x45950
ffffd000`256960d0 00000000`00000000 0xffffd000`256960f0

The ESET driver looks like the culprit of the crash. It seems that it probably filled up the stack, causing the crash.
I would remove ESET and see if the problem persists.
 
Re: BSOD 0x7f UPEXPECTED_KERNEL_TRAP_MODE caused by ntoskrnl.exe Windows 8.1 x64

If this stack is correct, ESET is calling an internal Kernel function directly (rather than going through the public API - KeExpandKernelStackAndCalloutEx, which then calls the KeExpandKernelStackAndCalloutInternal API, which isn't supposed to be called directly, hence why there's a public/MSDN documented version and an INTERNAL ... very obviously ... version). See for yourself:
Code: 
0: kd> !thread
THREAD ffffe00114c88880  Cid 0004.1068  Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor 0
Not impersonating
Owning Process            ffffe00110c9e8c0       Image:         System
Attached Process          N/A            Image:         N/A
Wait Start TickCount      993525       
Context Switch Count      11994          IdealProcessor: 1             
UserTime                  00:00:00.000
KernelTime                00:00:00.000
Win32 Start Address nt!ExpWorkerThread (0xfffff800520b1430)
Stack Init ffffd0002569bdd0 Current ffffd0002569b9f0
Base ffffd0002569c000 Limit ffffd00025696000 Call 0
Priority 13 BasePriority 13 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff800`53a37d28 fffff800`521607e9 : 00000000`0000007f 00000000`00000008 fffff800`53a37e70 ffffd000`25695fd0 : nt!KeBugCheckEx
fffff800`53a37d30 fffff800`5215e8f4 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff800`53a37e70 fffff800`52076663 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb4 (TrapFrame @ fffff800`53a37e70)
ffffd000`25695fd0 ffffe001`13724a22 : ffffe001`13724950 ffffd000`256960f0 00000000`00000000 00000000`00000000 : nt!KeExpandKernelStackAndCalloutInternal+0x53
ffffd000`256960c0 ffffe001`13724950 : ffffd000`256960f0 00000000`00000000 00000000`00000000 00000000`00000000 : em008_64+0x45a22
ffffd000`256960c8 ffffd000`256960f0 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : em008_64+0x45950
ffffd000`256960d0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 ffffd000`256966b0 : 0xffffd000`256960f0

0: kd> lmvm em008_64
start             end                 module name
ffffe001`136df000 ffffe001`137fe000   em008_64 T (no symbols)           
    Loaded symbol image file: em008_64.dat
    Image path: C:\Program Files\ESET\ESET Smart Security\em008_64.dat
    Image name: em008_64.dat
    Timestamp:        Wed May 20 06:37:58 2015 (555C8E36)
    CheckSum:         00000000
    ImageSize:        0011F000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
Looks like a recent version of ESET - I'd either talk to their support folks, or roll back to an older version that didn't cause this behavior (or, I suppose, remove entirely).
 
Re: BSOD 0x7f UPEXPECTED_KERNEL_TRAP_MODE caused by ntoskrnl.exe Windows 8.1 x64

I didn't notice that Cluberti, that is a very good point.

Would there be a particular reason for ESET to program their driver(s) to use the Internal function, and not the public API?
 
Re: BSOD 0x7f UPEXPECTED_KERNEL_TRAP_MODE caused by ntoskrnl.exe Windows 8.1 x64

Trying to get a perf boost maybe by cutting corners.
 
Re: BSOD 0x7f UPEXPECTED_KERNEL_TRAP_MODE caused by ntoskrnl.exe Windows 8.1 x64

Fair enough.
That seems like a risky gamble, which in this case has gone wrong.
 
Re: BSOD 0x7f UPEXPECTED_KERNEL_TRAP_MODE caused by ntoskrnl.exe Windows 8.1 x64

Considering it requires specific parameters being passed that the public function is supposed to protect (and if you screw up you bugcheck, hence why there's a public API to protect it), I'd say yes. Typical of security vendors though, if there's a less-than-wise way to do something, there's a likelihood someone will do it.
 
Re: BSOD 0x7f UPEXPECTED_KERNEL_TRAP_MODE caused by ntoskrnl.exe Windows 8.1 x64

Don't they check to make sure the parameters passed are valid?

Yeah, I'm not really surprised to be honest, there's always going to be somebody who thinks it's a good idea to bypass measures that are put in place, for a good reason.
 
Re: BSOD 0x7f UPEXPECTED_KERNEL_TRAP_MODE caused by ntoskrnl.exe Windows 8.1 x64

Yes, there's a check - but it causes a double fault. Double fault in user-mode? Not great, but just an app crash. DF in kernel == bugcheck. I remember seeing this with McAfee many years ago. You could tell when developers had cycled because bad / stupid behavior would come back, get fixed, then come back, get fixed, ad nauseum.
 
Re: BSOD 0x7f UPEXPECTED_KERNEL_TRAP_MODE caused by ntoskrnl.exe Windows 8.1 x64

OK, I removed ESET, gonna test it for days because this BSOD only come out once a day, sometimes longer.
 
Re: BSOD 0x7f UPEXPECTED_KERNEL_TRAP_MODE caused by ntoskrnl.exe Windows 8.1 x64

Let us know how it goes. Removal of ESET should resolve it, but let us know if you can.
 
Re: BSOD 0x7f UPEXPECTED_KERNEL_TRAP_MODE caused by ntoskrnl.exe Windows 8.1 x64

Jared said:
I didn't notice that Cluberti, that is a very good point.

Would there be a particular reason for ESET to program their driver(s) to use the Internal function, and not the public API?
Click to expand...
Perhaps Windows uses tail call optimization. If the return value of KeExpandKernelStackAndCalloutInternal is the return value of KeExpandKernelStackAndCalloutEx, a jmp may be used instead of a call to avoid creating a stack frame.
 
Re: BSOD 0x7f UPEXPECTED_KERNEL_TRAP_MODE caused by ntoskrnl.exe Windows 8.1 x64

After these days test, this BSOD seems gone. Thank you guys!
 
Re: BSOD 0x7f UPEXPECTED_KERNEL_TRAP_MODE caused by ntoskrnl.exe Windows 8.1 x64

muhahaa said:
Jared said:
I didn't notice that Cluberti, that is a very good point.

Would there be a particular reason for ESET to program their driver(s) to use the Internal function, and not the public API?
Click to expand...
Perhaps Windows uses tail call optimization. If the return value of KeExpandKernelStackAndCalloutInternal is the return value of KeExpandKernelStackAndCalloutEx, a jmp may be used instead of a call to avoid creating a stack frame.
Click to expand...
Doesn't appear to in the disassembly, although it's possible. It would depend on the compile of the app most likely, but again, I didn't see that.
 

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

Back
Top