Comments (3)
This is one of those class of errors that's frustrating to deal with. You can see from the decoded header that this is a WHEA error reported by a device driver (
CreatorId
andNotifyType
fields), but that's about it. The really interesting data would normally be present in theSection
field. The source data is there in the hex-encoded event, and the program warns you there's an extra 98 bytes of data it didn't decode:[WHEA_ERROR_RECORD] Header indicates error record contains 298 bytes but marshalled 200 bytes.
The reason it's not decoded is the structure of that data is completely up to the reporting driver. There's no standard structure, so it's impossible to decode without knowing the details of the structure used by the reporting driver. Worse, they're effectively all undocumented. We can glean a little information from the strings present in those 98 bytes:
Offset Bytes Ascii 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ------ ----------------------------------------------- ----- 0000000000000000 53 54 4F 52 50 4F 52 54 01 00 62 00 00 00 03 00 STORPORT� b � 0000000000000010 01 00 05 00 11 00 00 00 46 2E 28 1F 3F 90 EE 11 � � � F.(�?�î� 0000000000000020 B5 77 80 6E 6F 6E 69 63 73 00 74 00 6F 00 72 00 µw�nonics t o r 0000000000000030 6E 00 76 00 6D 00 65 00 00 00 00 00 00 00 00 00 n v m e 0000000000000040 00 00 00 00 00 00 00 00 4E 56 4D 65 20 20 20 20 NVMe 0000000000000050 00 4B 49 4E 47 53 54 4F 4E 20 53 46 59 52 44 32 KINGSTON SFYRD2 0000000000000060 30 00 0
So this looks to have been reported by the
storport
driver. The underlying hardware interface is presumably NVMe (stornvme
) and the device the event relates to is a "Kingston SFYRD20" (NVMe KINGSTON SFYRD20
). Understanding what all the other data means would require reverse engineering the relevant parts of at least thestorport
driver. Obviously, it'd be very helpful if Microsoft just published the structures in the Windows SDK, but they don't.
Thanks a bunch for the explanation, you rock!
Yes that is the main NVMe drive for the OS.
I hope I can disregard this crash as a random bug in the driver and not that the device is failing, it booted fine afterwards.
At least CrystalDiskInfo reports 100% health still and I don't notice any corruption as of writing this.
from decodewhearecord.
This is one of those class of errors that's frustrating to deal with. You can see from the decoded header that this is a WHEA error reported by a device driver (CreatorId
and NotifyType
fields), but that's about it. The really interesting data would normally be present in the Section
field. The source data is there in the hex-encoded event, and the program warns you there's an extra 98 bytes of data it didn't decode:
[WHEA_ERROR_RECORD] Header indicates error record contains 298 bytes but marshalled 200 bytes.
The reason it's not decoded is the structure of that data is completely up to the reporting driver. There's no standard structure, so it's impossible to decode without knowing the details of the structure used by the reporting driver. Worse, they're effectively all undocumented. We can glean a little information from the strings present in those 98 bytes:
Offset Bytes Ascii
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
------ ----------------------------------------------- -----
0000000000000000 53 54 4F 52 50 4F 52 54 01 00 62 00 00 00 03 00 STORPORT� b �
0000000000000010 01 00 05 00 11 00 00 00 46 2E 28 1F 3F 90 EE 11 � � � F.(�?�î�
0000000000000020 B5 77 80 6E 6F 6E 69 63 73 00 74 00 6F 00 72 00 µw�nonics t o r
0000000000000030 6E 00 76 00 6D 00 65 00 00 00 00 00 00 00 00 00 n v m e
0000000000000040 00 00 00 00 00 00 00 00 4E 56 4D 65 20 20 20 20 NVMe
0000000000000050 00 4B 49 4E 47 53 54 4F 4E 20 53 46 59 52 44 32 KINGSTON SFYRD2
0000000000000060 30 00 0
So this looks to have been reported by the storport
driver. The underlying hardware interface is presumably NVMe (stornvme
) and the device the event relates to is a "Kingston SFYRD20" (NVMe KINGSTON SFYRD20
). Understanding what all the other data means would require reverse engineering the relevant parts of at least the storport
driver. Obviously, it'd be very helpful if Microsoft just published the structures in the Windows SDK, but they don't.
from decodewhearecord.
Also, I accidentally hit enter half-way through the above comment, so if you got an email notification it's probably only got the mistakenly submitted comment. I'm closing this issue for now but feel free to reply if the above is unclear.
from decodewhearecord.
Related Issues (3)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from decodewhearecord.