systeminformer: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e) bugcheck on Win10 1809

Brief description of your issue

When I download the nightly, expand the zip and run the si exe I get a SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e) bugcheck under Windows 10 1809 LTSC

Steps to reproduce (optional)

  • download nightly
  • run it under Windows 10 1809

Expected behavior (optional)

No response

Actual behavior (optional)

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e) bugcheck on Win10 1809, so I compiled my own version and opened the dump, forced the load of my mismatched PDB to get a somehow better callstack:

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
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: fffff8034f47feb0, The address that the exception occurred at
Arg3: ffffd48738eca078, Exception Record Address
Arg4: ffffd48738ec98c0, Context Record Address

EXCEPTION_RECORD:  ffffd48738eca078 -- (.exr 0xffffd48738eca078)
ExceptionAddress: fffff8034f47feb0 (nt!ExpLookupHandleTableEntry)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 0000000000000000
   Parameter[1]: 0000000000000032
Attempt to read from address 0000000000000032



PROCESS_NAME:  System

READ_ADDRESS:  0000000000000032 

ERROR_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%p verwies auf Arbeitsspeicher bei 0x%p. Der Vorgang %s konnte im Arbeitsspeicher nicht durchgef hrt werden.

EXCEPTION_CODE_STR:  c0000005

EXCEPTION_PARAMETER1:  0000000000000000

EXCEPTION_PARAMETER2:  0000000000000032

EXCEPTION_STR:  0xc0000005

Environment (optional)

  • System Informer Rev. 5578
  • Windows 10 1809 LTSC 17763.3650 x64 German inside a VMware VM

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 53 (33 by maintainers)

Most upvoted comments

Version 3.0.6772 (a7cce79) runs fine on 1809, I see the driver loaded, the ++ in Titlebar to indicate full driver usage

image

So the issue can be finally closed 🥳🙌😍

Staging branch was merged. New driver release soon™️. I greatly appreciate everyone’s patience.

@stdedos

3.0.6550 doesn’t include the changes? There hasn’t been a nightly build released since 3.0.6550 as a precaution while we investigate #1668 and we’ll let everyone know when the issue is fixed with the next build 👍

Apologies for my pedantic-ness:

  1. What was the issue? (e.g. accessing Process handles)
  2. What is the solution? (e.g. accessing the API in a Microsoft-sanctioned way)

That’s a separate issue, but the fix is included. It’s described here https://github.com/winsiderss/systeminformer/issues/1525#issuecomment-1345621261

  1. Does the version-limiting apply still?
    1. If yes, does it totally and fully disable the kernel driver unless v < 20H1?

No, all Win10 x64/ARM64 are supported.

The delays were escalated mid-February and we got things moving again. I received an email yesterday that we should be good to go this week. However, there are still some administrative items to attend to with respect to portal registration. I don’t have a timeline for that. Hopeful that it will all get resolved soon.

I appreciate everyone’s patience here. The delays have simply been out of our control. Microsoft has been slow, as somewhat expected, unfortunately. But, they’ve been understanding and have been working with us to resolve the issues. Kudos to the folks over there for their time.

Thanks for emailing me the dump file. I’ve identified why dynamic data is not being loaded correctly. We have a plan to address this.

Are you able to update to LTSC 2021? This bug only affects legacy versions of Windows 10 while newer versions don’t have issues.

This bug affects current version of Windows Server 2019, which will be supported until Jan 9, 2029.

If the limit shows accurately for you, then maybe it’s time to merge the branch into main?

I can’t merge the changes until we get resolution from Microsoft. Since doing so will orphan the existing driver/client ABI. We touched base with Microsoft last week, hoping for resolution soon. Apologies for the delay - engaging with Microsoft can just take a while.

Hoping to get a resolution here mid-january.

any response from Microsoft? I still get the bugcheck with latest Patch 17763.3887

@dmex does “third party” label mean this is a Windows bug in 1809/Server 2019?

No, we’re waiting for Microsoft. The holidays are slowing down response times in our communication with them.

Unsure why you can’t load them. They’re here:

I’ve had similar issues in the past related to PDBALTPATH stripping the PDB filename from the debug header:

image

The other issue is how dbghelp doesn’t check the directory where the image is located:

image

PDBALTPATH strips the path and it becomes relative. Sometime later dbghelp tries using the filename but since it’s relative ends up in the current directory (the same location as the executable and not allowed) then won’t check elsewhere and just doesn’t load the PDB 🙄

forced the load of my mismatched PDB

@MagicAndre1981

  1. Copy the pdbs from \bin-signed\amd64\ into somefolder
  2. Set the symbol search path for the debugger using this exact format: D:\somefolder;SRV*C:\Symbols*msdl.microsoft.com

This way you can give proper stack traces that make sense unlike the homebrew mismatched PDB you’ve been using 😉