Analyzing a crash in Windows: what does the error message tell us?

The 64-bit time stamp is the time application's primary thread was created in 100-nanosecond intervals since January 1, 1601 (UTC) (this is known as FILETIME). The 32-bit timestamp is indeed in time_t format (it tells the time the module was created and is stored in the module's header).

I'd say 0x0002d160 is an offset from the module's load address (it seems too low for an absolute address). Fire up Visual Studio, start the debugger, take a look at the "modules" debug window. Your exe file should be listed there. Find the address where the module is loaded, add 0x0002d160 to that address and take a look at the disassembly at the resulting address. Visual Studio shows source code intermixed with the assembly, you should have no problem figuring out what source line caused the problem.

There isn't much you're going to be able to do postmortem with this information.

The useful bit of information is the exception code, 0xc0000005, which in this case just means an access violation. So you dereferenced null or some other bit of memory you didn't own.

Fault offset, I suspect, is the offset from where your DLL was loaded into memory, so you could in theory add it to your base address and find the offending code, but I'm not sure.

Your best bet for debugging this is to catch it in the debugger the next time this happens. You can use Image File Execution Options to run your app automatically in the debugger. Make sure you have symbols ready (consider building DEBUG if you're currently using RELEASE).

Debugging god John Robbins built a little tool called CrashFinder to help with situations like this:https://www.wintellect.com/crashfinder-2-8-yes-native-code-still-lives/

It's always a good idea to save PDBs for every build you release to the public (this sounds like a tool you only use in private, but it might be a good idea to keep the PDB symbols around for the latest build).