1. #1
    x BlueRobot's Avatar
    Join Date
    May 2013
    Location
    Minkowski Space
    Posts
    1,878

    Debugging Stop 0x122 - WHEA_INTERNAL_ERROR

    This is quite an obscure bugcheck, which doesn't really require much investigation, but since I haven't posted anything useful to Sysnative in a while (assignments etc.), I thought I would consider writing a small article regarding this bugcheck.

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Background:

    Stop 0x122 is primarily caused, as the name suggests, by a internal error occurring in the WHEA error reporting system implemented in Windows since Windows Vista. The parameters of the bugcheck give an indication into the the type of internal error, and thus what might need investigating.

    Microsoft has provided some documentation on the WHEA system, which will not provided here; I'll save it for a Stop 0x124 Complete Guide Debugging post.


    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Debugging Stop 0x122:

    As discussed earlier, this is mainly a parameter checking bugcheck, and then investigating the stack to find a little more information. Firstly, let's dump the bugcheck parameters with .bugcheck or .dumpdebug.

    Code:
    2: kd> .bugcheck
    Bugcheck code 00000122
    Arguments 00000000`0000000a 00000000`00000004 00000000`00000000 00000000`00000000
    The first parameter dictates the meaning of the second parameter, in case 0xA indicates that the second parameter is an error source type.

    Alternatively, we could have gathered the same information with the undocumented .dumpdebug command:

    Code:
    2: kd> .dumpdebug
    ----- 64 bit Kernel Mini Dump Analysis
    
    DUMP_HEADER64:
    MajorVersion        0000000f
    MinorVersion        00001db1
    KdSecondaryVersion  00000000
    DirectoryTableBase  00000001`67910000
    PfnDataBase         fffff800`0350b228
    PsLoadedModuleList  fffff800`0349fe90
    PsActiveProcessHead fffff800`03481b90
    MachineImageType    00008664
    NumberProcessors    00000008
    BugCheckCode        00000122
    BugCheckParameter1  00000000`0000000a
    BugCheckParameter2  00000000`00000004
    BugCheckParameter3  00000000`00000000
    BugCheckParameter4  00000000`00000000
    KdDebuggerDataBlock fffff800`0344b0a0
    ProductType         00000001
    SuiteMask           00000110
    WriterStatus        00000000
    MiniDumpFields      00000cff 
    
    TRIAGE_DUMP64:
    ServicePackBuild      00000100 
    SizeOfDump            00040000 
    ValidOffset           0003fffc 
    ContextOffset         00000348 
    ExceptionOffset       00000f00 
    MmOffset              00002080 
    UnloadedDriversOffset 000020d0 
    PrcbOffset            00002298 
    ProcessOffset         00006f98 
    ThreadOffset          00007468 
    CallStackOffset       00007900 
    SizeOfCallStack       00001000 
    DriverListOffset      00008c40 
    DriverCount           000000d1 
    StringPoolOffset      000101d0 
    StringPoolSize        00004698 
    BrokenDriverOffset    00000000 
    TriageOptions         ffffffff 
    TopOfStack            fffff880`0cbc7d48 
    BStoreOffset          00000000 
    SizeOfBStore          00000000 
    LimitOfBStore         00000000`00000000 
    DebuggerDataOffset    00008900 
    DebuggerDataSize      00000340 
    DataBlocksOffset      00014868 
    DataBlocksCount       0000001a 
      fffff800`034a0320 - fffff800`034a03bb at offset 00014a08
      fffff800`0348812c - fffff800`0348812f at offset 00014aa4
      fffff800`03488128 - fffff800`0348812b at offset 00014aa8
      fffff800`03410880 - fffff800`0341097f at offset 00014aac
      fffff800`034d6ca0 - fffff800`034d6ca3 at offset 00014bac
      fffff800`034d68a0 - fffff800`034d69bf at offset 00014bb0
      fffff800`0350b074 - fffff800`0350b077 at offset 00014cd0
      fffff800`0350b068 - fffff800`0350b06b at offset 00014cd4
      fffffa80`06cdb490 - fffffa80`06cdb677 at offset 00014cd8
      fffffa80`06cdc010 - fffffa80`06cdc1f7 at offset 00014ec0
      fffffa80`06cdcc10 - fffffa80`06cdcdf7 at offset 000150a8
      fffffa80`06cdc810 - fffffa80`06cdc9f7 at offset 00015290
      fffffa80`06cdc410 - fffffa80`06cdc5f7 at offset 00015478
      fffffa80`06cdd010 - fffffa80`06cdd1f7 at offset 00015660
      fffffa80`06cddc10 - fffffa80`06cdddf7 at offset 00015848
      fffffa80`06cdd810 - fffffa80`06cdd9f7 at offset 00015a30
      fffffa80`06cdd410 - fffffa80`06cdd5f7 at offset 00015c18
      fffffa80`06cde010 - fffffa80`06cde1f7 at offset 00015e00
      fffffa80`07303000 - fffffa80`073039f7 at offset 00015fe8
      fffff800`03473610 - fffff800`03473617 at offset 000169e0
      fffff800`03473618 - fffff800`0347361f at offset 000169e8
      fffffa80`0ebf4918 - fffffa80`0ebf5917 at offset 000169f0
      fffff800`03473620 - fffff800`03473627 at offset 000179f0
      fffff800`03473628 - fffff800`0347362f at offset 000179f8
      fffffa80`06ce3000 - fffffa80`06ce3fff at offset 00017a00
      fffff800`032da000 - fffff800`032dafff at offset 00018a00
      Max offset 19a00, 2e2f8 from end of file
    By using the MSDN bugcheck reference, we can see that the WHEA reporting system failed to allocate a error record for the a PCI express related error. All error records have the following structure:

    Code:
    2: kd> dt hal!_WHEA_ERROR_RECORD
       +0x000 Header           : _WHEA_ERROR_RECORD_HEADER
       +0x080 SectionDescriptor : [1] _WHEA_ERROR_RECORD_SECTION_DESCRIPTOR
    The error record contains important debugging information which we usually use in relation to a Stop 0x124.

    Now, let's investigate the call stack:

    Code:
    2: kd> knL
     # Child-SP          RetAddr           Call Site
    00 fffff880`0cbc7d48 fffff800`033e7693 nt!KeBugCheckEx
    01 fffff880`0cbc7d50 fffff880`00e73bcf nt!WheaReportHwError+0x123
    02 fffff880`0cbc7db0 fffff880`00e735f6 pci!ExpressRootPortAerInterruptRoutine+0x27f
    03 fffff880`0cbc7e10 fffff800`032d647c pci!ExpressRootPortInterruptRoutine+0x36
    04 fffff880`0cbc7e80 fffff800`03310d99 nt!KiInterruptDispatch+0x16c
    05 fffff880`0cbc8010 fffff800`0330fced nt!KxFlushEntireTb+0xa5
    06 fffff880`0cbc8050 fffff800`033339e0 nt!KeFlushTb+0x119
    07 fffff880`0cbc80d0 fffff800`032e809d nt! ?? ::FNODOBFM::`string'+0xae02 << nt!MiInitializePfn
    08 fffff880`0cbc8110 fffff800`032d876e nt!MmAccessFault+0xa7d
    09 fffff880`0cbc8270 fffff800`035bb5d4 nt!KiPageFault+0x16e
    0a fffff880`0cbc8400 fffff880`01776809 nt!NtQueryObject+0xa4
    0b fffff880`0cbc8510 00000000`00000001 aswSnx+0x1f809
    0c fffff880`0cbc8518 00000000`00000000 0x1
    We can certainly see some PCI related calls in the stack, which fits perfectly with the context of the thread we're investigating. The nt!WheaReportHwError indicates that we attempted to alert the rest of the operating system to a potential hardware failure, but then failed to do so for some reason, thereby leading to the bugcheck which we just experienced. The pci!ExpressRootPortAerInterruptRoutine gives a small indication to where the error may have occurred, this will require breaking into leaked PCI documentation if wish to understand more about potentially this function might be doing.

    Using the !dpx extension, we can see a much more informative stack, we gives light on some suspicious security drivers, which knowing McAfee and their poor range of products, could be meddling with Windows. Furthermore, there is signs of two security programs being run, which always usually means disaster!

    Code:
    2: kd> !dpx
    Start memory scan  : 0xfffff8800cbc7d48 ($csp)
    End memory scan    : 0xfffff8800cbc9000 (Stack Base)
    
                   rsp : 0xfffff8800cbc7d48 : 0xfffff800033e7693 : nt!WheaReportHwError+0x123
    0xfffff8800cbc7d48 : 0xfffff800033e7693 : nt!WheaReportHwError+0x123
    0xfffff8800cbc7d78 : 0xfffff80003364f82 : nt!WheaGetErrorSource+0x12
    0xfffff8800cbc7da8 : 0xfffff88000e73bcf : pci!ExpressRootPortAerInterruptRoutine+0x27f
    0xfffff8800cbc7e08 : 0xfffff88000e735f6 : pci!ExpressRootPortInterruptRoutine+0x36
    0xfffff8800cbc7e48 : 0xfffff80003218ae7 : hal!HalRequestSoftwareInterrupt+0x58
    0xfffff8800cbc7e78 : 0xfffff800032d647c : nt!KiInterruptDispatch+0x16c
    0xfffff8800cbc7e80 : 0x0000000000000111 :  Trap @ fffff8800cbc7e80
    0xfffff8800cbc7fe8 : 0xfffff80003310d99 : nt!KxFlushEntireTb+0xa5
    0xfffff8800cbc8048 : 0xfffff8000330fced : nt!KeFlushTb+0x119
    0xfffff8800cbc8068 : 0xfffff800034051de : nt!ExAllocatePoolWithTag+0xfe
    0xfffff8800cbc8078 : 0xfffff800033032de : nt!MiInsertPrivateVad+0x86
    0xfffff8800cbc8098 : 0xfffff80003303246 : nt!PsChargeProcessNonPagedPoolQuota+0x22
    0xfffff8800cbc8108 : 0xfffff800032e809d : nt!MmAccessFault+0xa7d
    0xfffff8800cbc8158 : 0xfffff800035d23eb : nt!NtAllocateVirtualMemory+0x75b
    0xfffff8800cbc8268 : 0xfffff800032d876e : nt!KiPageFault+0x16e
    0xfffff8800cbc8270 : 0x0000000000000000 :  Trap @ fffff8800cbc8270
    0xfffff8800cbc83d8 : 0xfffff800035bb5d4 : nt!NtQueryObject+0xa4
    0xfffff8800cbc8478 : 0xfffff80003680436 : nt!CmpCallCallBacks+0x4f6
    0xfffff8800cbc84d8 : 0xfffff800032d5e70 : nt!KiServiceLinkage
    *** WARNING: Unable to verify timestamp for aswSnx.SYS << avast!
    *** ERROR: Module load completed but symbols could not be loaded for aswSnx.SYS
    0xfffff8800cbc87c8 : 0xfffff800032ec2fc : nt!IopFreeIrp+0x11c
    0xfffff8800cbc8808 : 0xfffff800032efa7c : nt!IopCompleteRequest+0x54c
    0xfffff8800cbc8828 : 0xfffff800035b3397 : nt!CmpQueryKeyData+0xef
    0xfffff8800cbc8848 : 0xfffff80003405350 : nt!ExAllocatePoolWithTag+0x270
    0xfffff8800cbc8888 : 0xfffff80003405350 : nt!ExAllocatePoolWithTag+0x270
    0xfffff8800cbc88c8 : 0xfffff800034051de : nt!ExAllocatePoolWithTag+0xfe
    *** WARNING: Unable to verify timestamp for mfehidk.sys
    *** ERROR: Module load completed but symbols could not be loaded for mfehidk.sys << McAfee
    0xfffff8800cbc8978 : 0xfffff80003680436 : nt!CmpCallCallBacks+0x4f6
    0xfffff8800cbc8a08 : 0xfffff800035f4f97 : nt!IopXxxControlFile+0x607
    0xfffff8800cbc8a48 : 0xfffff800035aa7cd : nt!NtQueryKey+0x4eb
    0xfffff8800cbc8a88 : 0xfffff800035d1198 : nt!ObpFreeObject+0x128
    0xfffff8800cbc8b20 : 0xfffff8800cbc8bc8 : 0xfffff800035d1a34 : nt!ObpCloseHandle+0x94
    0xfffff8800cbc8b38 : 0xfffff800035f57f6 : nt!NtDeviceIoControlFile+0x56
    0xfffff8800cbc8ba0 : 0xfffff8800cbc8bc8 : 0xfffff800035d1a34 : nt!ObpCloseHandle+0x94
    0xfffff8800cbc8ba8 : 0xfffff800032d98d3 : nt!KiSystemServiceCopyEnd+0x13
    0xfffff8800cbc8bc8 : 0xfffff800035d1a34 : nt!ObpCloseHandle+0x94
    0xfffff8800cbc8c18 : 0xfffff800032d98d3 : nt!KiSystemServiceCopyEnd+0x13
    However, to conclude this breif article, there isn't much we can do with simply a Minidump. I would potentially investigate the pool resources and any other signs of resource stress on the system.

    References:

    https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx
    Last edited by x BlueRobot; 05-02-2015 at 07:23 AM.
    Machines Can Think

    We don't make mistakes; we just have happy accidents.


    • Ad Bot

      advertising
      Beep.

        
       

Similar Threads

  1. The Complete Guide for Debugging a Stop 0x9F
    By x BlueRobot in forum BSOD Kernel Dump Analysis Debugging Information
    Replies: 9
    Last Post: 07-24-2017, 05:23 PM
  2. DPC_WATCHDOG_TIMEOUT Debugging
    By Jared in forum BSOD Kernel Dump Analysis Debugging Information
    Replies: 0
    Last Post: 09-14-2014, 08:49 AM
  3. 0xF4 debugging
    By Jared in forum BSOD Kernel Dump Analysis Debugging Information
    Replies: 1
    Last Post: 07-02-2014, 09:53 PM
  4. Debugging TV
    By Shintaro in forum BSOD Kernel Dump Analysis Debugging Information
    Replies: 1
    Last Post: 09-12-2012, 10:03 AM
  5. Debugging TV
    By Shintaro in forum BSOD, Crashes, Kernel Debugging
    Replies: 1
    Last Post: 09-12-2012, 10:03 AM

Log in

Log in