Windows 10 Mail App Forensics

6 min readMay 27, 2019

While working on a forensics case, I stumbled across a folder in AppData\Local called “Comms”. Not knowing what this was at the time, I glanced through and realised that these are logs and artefacts of the Windows 10 Mail application.

For this blog post, I was able to replicate the findings in a Windows 10 virtual machine by creating some test email accounts. Fun fact! You know how there are services for temporary email addresses like Guerrilla Mail? There are also temporary phone numbers you can use incase you need a 2FA code for email account verification (such as, or this non-dodgy site). Pretty cool stuff.

Anyways, once you load up the mail app and start firing away some emails, the logs are written almost instantaneously. The directory in question is:

  • \Users\<username>\AppData\Local\Comms\Unistore\data

As shown below, this directory’s sub-directories are a list of numerals that contain folders in alphabetical order. The numbers represent a different segment of an email, which I could have figured out just by looking within each folder, but I was lucky to find this post along the way to help me out:

Directory Listings for the Windows 10 Mail App Artefacts

Let’s go through each of them:

  • AppData\Local\Comms\Unistore\data\0; Windows phone data
  • AppData\Local\Comms\Unistore\data\2; contact lists within the account
  • AppData\Local\Comms\Unistore\data\3; the contents/body of the email
  • AppData\Local\Comms\Unistore\data\5; calendar invitations
  • AppData\Local\Comms\Unistore\data\7; email attachments
  • AppData\Local\Comms\Unistore\data\33; contents of invitations, maybe

All of the files contained within these sub-directories are stored as .dat files. As @cruzhams wrote on Twitter, especially for the contents of emails stored in \data\3, the easiest way to parse these are to save them as .html files, and open them within a browser. Unsurprisingly, the best results are when they’re viewed with Internet Explorer. Otherwise, FTK does a good job at parsing them too.

Here’s the difference between displaying .dat files (this example from \data\3) normally:

And viewing the email after it’s exported and saved as a .html file. Saves your brain from processing all those html tags:

The .dat files in this directory represent calendar invitations, however from what I’ve found during this investigation, it unfortunately doesn’t save many juicy details… see for yourself in the example below. OSForensics was able to show more metadata by reading it in the Hex/Strings view, which had the name of the appointment, and who scheduled it in.

XWays displaying calendar invitations

The email attachments contained here can be accurately parsed using XWays and OSForensics, so you’re able to view the actual image, spreadsheet, word document etc. XWays nicely informs you of the file type of the attachment as found in the email, which is displayed in the Type column:

Now this is purely speculation on my part. I haven’t been able to find any research about this sub-directory, and my sample size is small, BUT, I was pleasantly surprised when OSForensics was able to give me something of value. Unfortunately, this was linked to my work email account, so I’m not able to show much of the contents, but I do believe the .dat files within \data\33 shows you the body of appointments or meeting invitations that have been sent to an email.

While a web browser will show you meaningless text:

OSForensics however, can extract strings and display the hex/ascii content of the appointment. I thought this was neat.

OSForensics parsing .dat files in \data\33

You can see references to “Updated Webex Details Jan-2019”, and “ARCHIVED PRESENTATIONS”. I checked my inbox for these strings, and certainly enough, it displayed this text as the body of a webex meeting that I had been invited to attend earlier in the year.

Now that we’ve gone through most of the directories within \AppData\Local\Comms\Unistore\data\, there is another artefact that stores similar data within the Comms directory.

Contained in \AppData\Local\Comms\UnistoreDB, there is a database called store.vol which, as the name suggests, stores email content in one repository. The notable tables within this database include Message, Contact, Appointment, Attachment, and Recipient.

Extracting this database for viewing is a little difficult as it’s locked or in use by a Windows program. To get around this, I used OSForensics, available for free as a 30 day free trial. Once this has been installed, create a case, open the File System Browser, and save store.vol to disk like so:

Using OS Forensics to Extract store.vol

Double-clicking store.vol here only gets you so far. You can see below that the String Viewer offered some email metadata and contents, but it wasn’t being presented in the way that I hoped.

OSForensics String Viewer to search store.vol for email data

Funnily enough, OSForensics has an ESEDB Viewer! Exactly what we need!
As I’ve previously mentioned, you’ll see the tables to the left of the viewer that you can drill down into. I’ve included some screenshots below to share what this looks like:

Using OSForensic’s ESEDB Viewer to parse store.vol

The Message table shows you what you’d expect, the body of the email (what was displayed in Unistore\data\3). However to find the person it was sent to, there is a separate table called Recipient, which is displayed in the bottom right. Towards the left, you’ll see the Appointment table, which, amongst all the default holiday entries, you’ll find ‘Meeting with Bob’, where Alice wanted to meet Bob in Trafalgar Square.

Now that the easy part is over, I wanted to share the internal struggle I faced trying to find software that would correctly parse ‘store.vol’. I attempted to use NirSoft’s ESEDatabaseView, which was able to extract some metadata, but not the contents of the email. You’ll see similarities below between ESEDatabaseView and OSForensics in terms of the column naming, or lack thereof.

Attempting to use NirSoft’s ESEDatabaseView to parse store.vol

I even tried Autopsy (this is what desperation looks like). It parsed some email content, sure, but where are the tables? This was essentially a glorified version of OSForensics’ String Viewer; notice ‘Extracted Content’ and ‘Indexed Data’.

Attempting to use Autopsy to parse store.vol

Thankfully, I discovered ESEDB Viewer in OSForensics, and didn’t have to worry much about these other tools.

This was fun! Over and out.




Your one and only source into the scandalous life of a DFIR consultant.