Are you sure you extract all the available Volume Serial Numbers (VSNs) that reside in the Windows 10 Event Log “Microsoft-Windows-Partition%4Diagnostic.evtx”?

Published Date : December 2, 2020 , atropos4n6

[UPDATE 1/2 (May 2021): We are really grateful that this article made it to the finals of this year's Forensic 4:cast awards, for the category "DFIR Article of the Year"!!! Your nominations got us there. I cannot describe in words how thankful I am to this DFIR community for this nomination! If you enjoyed our article and have not yet voted, voting is still open here: . Be sure to also check the great work that has been done, in the other two articles that made it to the finals as well.]

[UPDATE 2/2 (May 2021): I am super excited to announce that a more formal version of this article has been published by DFIR Review. We are thankful to both our reviewers and to this great community, for the opportunity to share our work and the motivation to keep pushing forward our DFIR research. You can find our published paper here:]

Greetings DFIR community! It has been a while since my last post, but juggling between work, life and research can be intimidating, as many of you already know. Nonetheless, today I am super excited to share with you the results of my latest collaborative research. We finally submitted our work for review and I cannot wait to hearing our reviews (fingers crossed)! This research post was a combined effort of me and another two amazing individuals, who are both DFIR-researchers and digital forensic experts, Alexandros Vasilaras and Dimitrios Katsoulis. It is thanks to Dimitrios, that we also have a tool (written in Python) to share with our DFIR community, so as to help you all skip the trouble of manually parsing VSNs. But before writing about this, let's start from the beginning.

Our main goal is to present to you how to fully utilize this Event Log, so as to extract current and previously existed VSNs of a device (either Unpartitioned or with MBR partition scheme) with multiple Volumes. This presentation will assist in attributing LNK files and Jump Lists to such a device, even if the device has been formatted or worse, wiped.


I feel obliged to highlight the fact that this research is a non-profit one. We have not collaborated with any forensic software company, or any other third party entity. We do not have any personal or any kind of profit out of it. This research is merely a result of our own interest and personal time. By sharing this research, we are only trying to help the DFIR community and contribute back to it. We highly appreciate and use every and each one of the tools mentioned throughout this research. We hope that this research will be beneficiary for both DFIR practitioners and forensic software companies. Thank you.

Background Work

Windows 10 introduced the Event Log “Microsoft-Windows-Partition%4Diagnostic.evtx”. This log is without any doubt of vital importance for both digital forensic examiners and incident responders. We are not the first ones to analyze this artifact, in pursue of extracting and interpreting its valuable information. Harlan Carvey [1], Jason Hale [2][3], forensixchange [4] and Costas K. [5] have all analyzed and shed light into what can be stored in this Event Log.

On the other hand, one point that has not yet been covered efficiently in the existing literature, is that in this Event Log, there can be found both current and previously existed VSNs of the same device, as well as up to 3 VSNs of a device with multiple Volumes. In our research, we attempted to address this point, in order to unveil more of the hidden gems located in this Event Log, as well as highlight the importance of including its analysis in everyday investigations.

Event Log “Microsoft-Windows-Partition%4Diagnostic.evtx”

In this Event Log, information is stored about both removable devices (USB Sticks, SD Cards, External Hard Disks) and internal hard disks of a computer (including the disk that runs the operating system). More particularly, this log stores information either when someone plugs in or out one of these devices, or after booting the computer. But what type of information does it store exactly?

Previous work [2][3][4][5], has answered this question in detail. Despite that, there are still fields that have not been explained, but thankfully most of them are self-explanatory (e.g. IsTrimSupported). It is out of the scope of this research to stressfully present all of the remaining fields in this log file. Before describing our methodology, we will present some of the Event Log’s fields, emphasizing on those that are most needed. Due to the fact that when a device gets disconnected, many of the afore-mentioned values will be 0, we are entirely focusing on presenting the equivalent values to when a device (with MBR partition scheme) gets connected:

System Section:

  • EventID: The ID of the log file. Will always be 1006.
  • TimeCreated [SystemTime]: Timestamp of the displayed event. In this case, the timestamp that plug in/out occurs, or the timestamp of the internal disk checkup at boot. It is stored in UTC. (Be aware though, that when using Windows’ Event Viewer, timestamps are presented in local time).
  • EventRecordId: Unique number assigned to each record inside the log file (increments by one).
  • Computer: Computer name.
  • Security [UserID]: User’s SID. Will always be S-1-5-18 (User SYSTEM).

EventData Section:

  • DiskNumber: In our analysis, we found this number varying in a range between 0-3, with 0 being assigned at the disk running the OS.
  • IsSystemCritical: This value is usually false, apart from when DiskNumber was 0.
  • BytesPerSector: Bytes per sector (usually 512-defined by the manufacturer) of the device.
  • Capacity: The total capacity of the device (in bytes).
  • Manufacter: The manufacturer of the device. Not always accurate.
  • Model: Model of the device. Not always accurate.
  • SerialNumber: Serial number of the device.
  • ParentId: Information about the device, including Vendor ID, Product ID, Serial Number (potential correlation with registry files).
  • PartitionStyle: The partition scheme of the device. MBR is 0. GPT is 1.
  • PartitionCount: Number of partitions of the device. Not to be trusted.
  • Mbr: Raw dump of the first 512 bytes of the Master Boot Record of the device. Contains device’s Disk Signature and Master Partition Table.
  • Vbr0: Raw dump of the Volume Boot Record of the device’s 1st Partition. Contains the VSN of this Partition.
  • Vbr1: Raw dump of the Volume Boot Record of the device’s 2nd Partition. Contains the VSN of this Partition.
  • Vbr2: Raw dump of the Volume Boot Record of the device’s 3rd Partition. Contains the VSN of this Partition.
  • Vbr3: In our analysis, we found that this field is not populated with the raw dump of the Volume Boot Record of the device’s 4th Partition. If someone wants to determine the existence of a 4th Partition, he should examine the Master Partition Table.

As can be seen above, this Event Log not only stores the VSN of the 1st Partition of a connected device, but also the VSNs of the 2nd and 3rd Partitions. Even after a user has formatted his device (leading to the loss of the Volume’s VSNs for good), previous VSNs can still be retrieved from the Event Log and attributed to his device.

These features are what make this log one of the most valuable sources of information, when attributing VSNs to devices is concerned.

Before presenting our analysis, it must be clarified that when a device with GPT partition scheme is connected, the values that are stored are not the same. This Event Log requires further research for the purpose of fully understanding what is logged, when devices with such partitioning scheme, are connected to the computer. Furthermore, the nature of the device (e.g. SSD Drive) and the type of connection (e.g. SATA hard disk plugged in an USB adapter and then in the computer) will populate some of the above-mentioned fields differently.

What is more, bear in mind that this log’s lifespan is relatively short (Event Log gets cleared every Windows 10 major update). On the other hand, between minors updates it remains as is (in our analysis we updated our system from 19041 to 19042 and it remained intact).

Software Used

Operating System:

  • Microsoft Windows 10 Pro 2004 Build 19041 (Original Tests)
  • Microsoft Windows 10 Pro 20H2 Build 19042 (Updated previous OS to test if the Event Log got cleared)

Parsing LNK Files and JumpLists:

  • JLECmd
  • LECmd
  • AXIOM 4.7

Event Log Viewing, Parsing and Analyzing:

  • Event Viewer
  • FullEventLogView v1.58
  • Evtx Explorer/EvtxECmd
  • AXIOM 4.7
  • USB Detective 1.6.1

Methodology Used

For this analysis, we used a Kingston Patriot USB device with 32GB, which we plugged in/out several times in a computer running Windows 10 2004 (Build 19041). The USB device had MBR partition scheme and 4 equals in size NTFS partitions.

One feature that characterizes uniquely a Volume/Partition inside a device, is its Volume Serial Number. VSN is located inside the Volume Boot Record and is assigned during high level format. Its offset and length vary, depending on the File System used by the device (NTFS, ExFAT etc.). VSN is used by LNK Files and Jump Lists to point at the Volume where their target files reside (or used to reside before a wipe/format action took place on the device). Attribution is one of the reasons why VSN is so important in digital forensic investigations.

Another important feature that identifies a device with MBR partition scheme (GPT uses disk GUID instead), is its Disk Signature. Disk Signature is located inside the Master Boot Record, at offset 0x1b8 (4 bytes long-LE) and is assigned when the device gets partitioned.

Our entire analysis focused on “Microsoft-Windows-Partition%4Diagnostic.evtx”. To that extent, we did not examine any registry files of the target computer, that could assist us in any kind of correlations.

To begin with, we connected/disconnected the USB device and observed how the log got populated. Afterwards, we created and accessed various files in all of the USB device’s Partitions. Our purpose was to create LNK files and Jump Lists that could help us make connections.

After a certain amount of data was created, we started deleting the partitions, one by one, starting from the last one. As a result, the whole USB device appeared as unallocated space. The USB device was then completely re-formatted into 3 “new” NTFS Partitions. This whole process was repeated another time, resulting in the creation of 1 “last” NTFS partition that took up the whole available space.

Lastly, for completeness purposes, we made another 2 connections/disconnections. We connected a Kingston 8GB device with FAT32 and EXT3 file systems (2 Partitions). Then we formatted the FAT32 Partition and created an exFAT instead. After re-connecting the USB device, we checked if the same or similar information was stored in the Event Log.


Our analysis consists of 4 phases namely: Phase 1 (4 Partitions), Phase 2 (format and 3 Partitions), Phase 3 (format and 1 Partition) and Phase 4 (FAT32, EXT3 and exFAT).

Phase 1-(4 Partitions)

Firstly, we collected all the available LNK Files and Jump Lists that we created and documented all the Volume Names and VSNs they included (using JLECmd, LECmd and AXIOM 4.7 - See Image 1):

Image 1: VSNs, Volume Names of Phase 1

Then we analyzed the Event Log and managed to attribute 3 of the above VSNs and their respective Volume Names to the same device. We failed to attribute the 4th (presented in Image 1 within the red box) as it was not stored inside the log. Regardless of that, we managed to prove that a 4th Partition indeed existed in this device, by examining Master Partition Table’s entries inside MBR. In NTFS Volumes, VSN starts at offset 0x48 (4 bytes long-LE) of the VBR. See below, fractions of the Event Log, that helped us in attributing the VSNs (See Image 2):

Image 2: Information about the device stored in the Event Log

Serial Number: 007B01149030
Disk Signature: CE0DF460
How Many Partitions (from MPT): 4
1st Volume File System: NTFS
1st Volume Serial Number: C8B91B23
2nd Volume File System: NTFS
2nd Volume Serial Number: 76D3169C
3rd Volume File System: NTFS
3rd Volume Serial Number: 56EE2567
4th Volume File System: Could not be determined by analyzing the log
4th Volume Serial Number: Could not be determined by analyzing the log

Overlooking “Microsoft -Windows-Partition%4Diagnostic.evtx”, could possibly mislead the investigator into hypothesizing that there were many devices connected to the computer, due to the diversity of VSNs, Volume Names and assigned Drive Letters. Whereas, if this log is included in the analysis, there is a lot of information that could help him make safer assumptions, about the number of devices plugged in the computer.

Phase 2-(format and 3 Partitions)

After deleting all the Partitions of the USB device, we created 3 new NTFS Partitions and repeated the same process as Phase 1. The results were similar. Following is a list of all the VSNs that were retrieved from the LNK files we created in Phase 2 (See Image 3):

Image 3: VSNs, Volume Names of Phase 2

Once again, the Event Log kept tracking the various VSNs, allowing us to keep attributing them to that particular device. Let’s take a look at another Event ID 1006 entry that was logged during Phase 2 (See Image 4):

Image 4: Information about the device stored in the Event Log

Serial Number: 007B01149030
Disk Signature: CE0DF460
How Many Partitions (from MPT): 3
1st Volume File System: NTFS
1st Volume Serial Number: 54F63E46
2nd Volume File System: NTFS
2nd Volume Serial Number: D803E772
3rd Volume File System: NTFS
3rd Volume Serial Number: 30239D59

This time the Event Log helped us attribute all the VSNs to the device. We validated this match, comparing Partition entries in MPT and corresponding VSNs. We will skip the results of Phase 3, as they were similar to those of Phase 1 and Phase 2.

To conclude with, we will present what information was stored in the Event Log during Phase 4.

Phase 4-(FAT32, EXT3 and exFAT)

After plugging in the USB device with the FAT32 and EXT3 Partitions, the following information was logged in the Event Log (See Image 5). In FAT32 Volumes, VSN starts at offset 0x43 (4 bytes long-LE) of the VBR:

Image 5: Information about the device stored in the Event Log

Serial Number: 001CC0EC3458F110E5F31400
Disk Signature: 0047356E
How Many Partitions (from MPT): 2
1st Volume File System: FAT32
1st Volume Serial Number: 6A844219
2nd Volume File System: Could not be determined by analyzing the log
2nd Volume Serial Number: Could not be determined by analyzing the log

Unfortunately, EXT3 Partitions, being a File System from a different operating system, are not recognized by this Event Log and as a result no relevant information is logged. However, we found VSN for the FAT32 Volume and managed to prove that a 2nd Partition indeed existed in this device, by examining Master Partition Table inside MBR.

Closing this analysis, after plugging in the USB device with the exFAT and EXT3 Partitions, the following information was logged in the Event Log (See Image 6). In exFAT Volumes, VSN starts at offset 0x64 (4 bytes long-LE) of the VBR (See Image 6):

Image 6: Information about the device stored in the Event Log

Serial Number: 001CC0EC3458F110E5F31400
Disk Signature: 0047356E
How Many Partitions (from MPT): 2
1st Volume File System: exFAT
1st Volume Serial Number: 2C50410B
2nd Volume File System: Could not be determined by analyzing the log
2nd Volume Serial Number: Could not be determined by analyzing the log

Once again, no information could be retrieved for the EXT3 Partition, whereas the VSN for the exFAT Partition was successfully recovered, along with the 2 entries in the MPT of the MBR.

Tool Development

We developed a tool (written in Python), that helps automate the process of extracting all the logged VSNs that reside in the “Microsoft-Windows-Partition%4Diagnostic.evtx”, for each device that was connected to the target computer. During our research, our tool appeared to be the only one that could successfully extract all stored VSNs (current and previously existed throughout the whole log) from 1st, 2nd and 3rd Partitions respectively, whereas other tools were limited to the VSN of the 1st Partition only.

Currently, our tool extracts effectively VSNs from devices that:

  1. Are either Unpartitioned or have MBR partition scheme,
  2. Have up to 3 Volumes. Moreover, information about the existence of a 4th Partition, can be extracted from the Event Log as well (up to this day however, VSN for the 4th VBR is not stored in the Event Log) and
  3. Have Volumes (or more specifically VBRs) that belong to any modern Microsoft Windows File System (namely NTFS, FAT32 and exFAT).

Using our tool, investigators are able to search for a specific Serial Number of a device, throughout “Microsoft-Windows-Partition%4Diagnostic.evtx”, in which case the tool will return a list of VSNs that ever existed in it. Investigators can choose to output the result of the tool to a report file (.html or .csv format supported).

Examining the output report, investigators can also find out when approximately a particular VSN changed, and even determine if a format operation or any other masquerade attempt, took place on the device itself (such as manually altering the VSN of a given volume of the device, with a hex editor).

In addition, they are given the option to extract information (including the stored VSNs for any device that has the 3 above-mentioned characteristics) for all the devices that were connected to the target computer. This method, supports exporting the results to a report file as well (Full Report feature). This report will offer a holistic view of the computer and historical information about device connections.

Both tool and its documentation, along with the event log we used in our analysis, are available here:

Link to the event log we used throughout this research can be found here:


Taking everything into consideration, in this post we tried to outline the importance of examining “Microsoft-Windows-Partition%4Diagnostic.evtx”, especially in cases where device attribution is needed. Even though this artifact was first detected years ago, we have not yet fully explored its wealth of information. Nevertheless, we showed how to manually extract all the available VSNs that are stored in it, as well as developed a tool to help automate this process. There is definitely room for further research of this Event Log, but hopefully the reader will find value in some of the major artifacts that can be found in it.

Future Work

We are planning to analyze how this Event Log handles GPT partition-schemed devices, as well as how it handles different file systems. We have some preliminary results, but they need further investigation.


[1] Carvey, H., 2017. Windows Incident Response: Stuff. Windows Incident Response. URL (accessed 11.29.20)

[2] Hale, J., 2018. USB Device Tracking using the Partition/Diagnostic Event Log - Part 1, 2018. . Digital Forensics Stream. URL (accessed 11.29.20).

[3] Hale, J., 2018. USB Device Tracking using the Partition/Diagnostic Event Log - Part 2, 2018. . Digital Forensics Stream. URL (accessed 11.29.20).

[4] Name, Y., n.d. USB storage forensics in Win10 #1 - Events [WWW Document]. Forensics|Exchange. URL (accessed 11.29.20).

[5] kacos2000/Win10 [WWW Document], n.d. . GitHub. URL (accessed 11.30.20).

I really hope you enjoyed this post. If you found value in it, share it with any DFIR fellow that might find it useful. In my next post, Dimitrios will share with us, a full walkthrough of his tool "Partition%4DiagnosticParser". Stay tuned!

8 Replies to “Are you sure you extract all the available Volume Serial Numbers (VSNs) that reside in the Windows 10 Event Log “Microsoft-Windows-Partition%4Diagnostic.evtx”?”


Thank you for posting your research and parsing tool. Very useful details. I hope to try and replicate some of your testing scenarios.
Based on some parsing and review of my client’s event logs, I think there could be some misinterpretation of data by identifying devices by the serial number field. I have seen instances where the device parent id and serial number fields are constant but the other describing details like manufacture, model, capacity etc… are different. My hunch is this is a USB to SATA bridge. In this situation, all of the VSN values will be attributed to a single device when in fact they are not.

Thank you Mike, I really hope that both the post and tool will help you with your case. Our tests verify your statement, that when using USB-adapters to attach devices to a computer, the fields Manufacturer and Model get populated by the adapter’s information (it also stated in the post). But thankfully, serial number still gets populated by the media’s serial number.
It is still the same media, as identified by its serial number, no matter what kind of USB-adapter is used to attach it to the computer. One may use a docking station or a USB-to-SATA cable, a USB hub, or something else to connect the media to the computer, but no matter what he used, it is the same media. I hope you understand my point.


Hi – after reading your response I had to second guess what I had observed in the event log but I re-examined it today. I’m seeing a single USB device where the media’s serial number is the same value across multiple disks. The manufacturer, model and capacity fields are showing different disk information. Under that scenario, there is only one entry in your tool’s output with all of the vsn values.
Under Enum\USB, the ClassGUID is {4d36e97b-e325-11ce-bfc1-08002be10318} and the DeviceDescr shows “USB Attached SCSI (UAS) Mass Storage Device”. What caught my eye was the CompatibleIDs value shows protocol 62, where I normally see protocol 50. The Microsoft web page associates the device setup class with “Uaspstor.sys and is the class driver for SuperSpeed USB devices that support bulk stream endpoints”. So maybe my particular event log is showing peculiar results because of some USB3 to SATA adapter.
For my parsing, I was using the registryID uuid value as the unique identifier for a disk. I do not know if that uuid will remain contant if the disk is reformatted. I hope to be able to test that at some point.

Great news. This is exactly the scenario that I was describing in my previous response. If you test this scenario, it would be great if you could share your results with us, in another response. Thank you.

Hi Atropos4n6, kudos to your great work!

I gave your tool a shot analyzing some of my cases, unfortunately it didn’t work. I’ve examined the evtx file manually and to my horror, VBR0 in many cases aren’t recorded anymore. 🙁

I’ve also read up on this one:

At this stage, I’m not sure how a linkage between USB device serial to VSN can be drawn conclusively. Any idea?

Have you look at USB Detective ( It’s really powerful but I’ve seen it made some educated projections… Very useful but I always manually verify so I only report conclusive findings.

Thank Albert! I agree with you, you should always verify the results of any tool you use. There is a number of things you can check to verify this result. Are you sure your media is either Unpartitioned or partitioned with MBR partition scheme? If your media uses GPT partition scheme, this information will not be recorded. Also, what is the File System of the first partition of your media? If it is not FAT32, exFAT or NTFS it is high likely that it will not be recorded as well. Hope this helps.


Hi Atropos4n6
Have you analyzed the information recorded for medias with GPT partition scheme?
For GPT partitions, do you know of any other method to map VSN to a device, without having access to the device?

No we haven’t. During our experiments no information was recorded for these devices within this event log type.
Unfortunately, I do not know if there is another artifact that could assist you for this task.
Wish you best of luck with your research.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.