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)
Version 3.0.6772 (a7cce79) runs fine on 1809, I see the driver loaded, the ++ in Titlebar to indicate full driver usage
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 đ
Thatâs a separate issue, but the fix is included. Itâs described here https://github.com/winsiderss/systeminformer/issues/1525#issuecomment-1345621261
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.
This bug affects current version of Windows Server 2019, which will be supported until Jan 9, 2029.
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.
any response from Microsoft? I still get the bugcheck with latest Patch 17763.3887
No, weâre waiting for Microsoft. The holidays are slowing down response times in our communication with them.
Iâve had similar issues in the past related to PDBALTPATH stripping the PDB filename from the debug header:
The other issue is how dbghelp doesnât check the directory where the image is located:
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 đ
@MagicAndre1981
somefolderD:\somefolder;SRV*C:\Symbols*msdl.microsoft.comThis way you can give proper stack traces that make sense unlike the homebrew mismatched PDB youâve been using đ