32-bit exception information is sometimes sign-extended causing confusion when decoding Windows error codes #893
Comments
gabrielesvelto
added a commit
to gabrielesvelto/rust-minidump
that referenced
this issue
Nov 13, 2023
When interpreting Windows status code that have been stored as 64-bit values, ignore the upper 32 bits as they're likely to contain bogus data. In particular windbg.dll seems to sign-extend the 32-bit value when storing it as a 64-bit one. Note that we're not really throwing away data with this patch as the status codes are supposed to be 32 bits, so we shouldn't have relied on the upper 32 bits being cleared in the first place. This fixes issue rust-minidump#893
gabrielesvelto
added a commit
to gabrielesvelto/rust-minidump
that referenced
this issue
Nov 24, 2023
When interpreting Windows status code that have been stored as 64-bit values, ignore the upper 32 bits as they're likely to contain bogus data. In particular windbg.dll seems to sign-extend the 32-bit value when storing it as a 64-bit one. Note that we're not really throwing away data with this patch as the status codes are supposed to be 32 bits, so we shouldn't have relied on the upper 32 bits being cleared in the first place. This fixes issue rust-minidump#893
gabrielesvelto
added a commit
that referenced
this issue
Nov 24, 2023
…d. (#894) When interpreting Windows status code that have been stored as 64-bit values, ignore the upper 32 bits as they're likely to contain bogus data. In particular windbg.dll seems to sign-extend the 32-bit value when storing it as a 64-bit one. Note that we're not really throwing away data with this patch as the status codes are supposed to be 32 bits, so we shouldn't have relied on the upper 32 bits being cleared in the first place. This fixes issue #893
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've noticed that some Windows crashes for 32-bit Firefox & Thunderbird builds where showing odd values for the crash reason, for example this one. The crash reason is
EXCEPTION_IN_PAGE_ERROR_READ / 0xffffffffc0000006which is clearly wrong. Sifting through more crashes I figured out that it seems that windbg.dll is sign-extending Windows status codes when writing them to the minidump's exception streamexception_informationarray (which is made up of 64-bit values). To address this issue we'll have to either clear or ignore the upper bits of the elements pulled out of theexception_informationarray. I'd like the fix to be as small as possible as I don't want to accidentally throw away meaningful data just because of an implementation bug in some closed-source library.The text was updated successfully, but these errors were encountered: