Repository navigation
Report the faulting module, offset and a call stack for native crashes - #138
Merged
Merged
Conversation
Crash reports kept only an allow-listed faulting module name and no offset, so two 2.6.12 access violations could only be attributed to wisp.exe. The Event Log module name is now kept whatever it is (a bare file name; paths are dropped) together with the module version and the fault offset, and the native renderer installs a vectored exception handler that writes the faulting address and a module+offset call stack to the crash store; the next run attaches it to the report and sends it to Wisp Tools.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Crash reports stop guessing about where a native fault happened.
WindowsFaultEventReaderkeeps any faulting module file name (lower case, letters, digits,.,_,-, with a.dll/.exe/.sys/.drvextension, orunknown) instead of an allow-list that dropped hooks other software injects (RTSS, overlays), and keeps the module's version. Paths are still rejected.Wisp.NativeRenderer.dllinstalls a vectored exception handler at startup (WispCrashCaptureInstall). On an access violation (outside the null page, which the runtime uses for its own null checks), in-page error, illegal or privileged instruction, misalignment, stack-buffer overrun or heap corruption, it writes one bounded record, without allocating or handling the exception, toCrashReports/native-<run id>.txt: exception code, thread, faulting address as module+offset, the access kind and address, and a call stack of up to 48 frames as module+offset. At most three records per process.PreviousRunRecoveryattaches the previous run's record to the crash report (RecoveredExitInfo.Native), the report text lists it, and the incident sent to Wisp Tools carriescrash.offset,crash.moduleVersion,crash.faultModule,crash.faultOffsetandcrash.frames. The incident signature is unchanged, so grouping is stable. Tools accepts and shows these fields (wisp-site PR "Accept and show the faulting module, offsets and a native call stack on crash evidence").Why
Two 2.6.12 access violations could only be attributed to
wisp.exe: the Event Log offset was never exported and the real faulting module was filtered by the allow-list. With this, the next fault names the module, its version, the offset and the stack.Checks
/W4 /WX; the contract tests (Build-NativeRenderer.ps1 -RunContractTests) includeCheckCrashCapture(record format, module naming, access details, stack, buffer bound, idempotent install) and pass on the owner's PC with a GPU.NativeCrashCaptureTests(parsing the last complete record, sanitising, frame bounds, read-once file handling) and updatedWindowsFaultEventReaderTests(any file name kept, paths dropped, module version kept when well formed). CI runs the suite.