BSOD on execution about memprocfs HOT 10 CLOSED

Thanks for the update. I'm glad the BSOD is resolved (at least from my point of view; it seems like you accidentally tripped over an issue in Sysmon though ;)

Also that the memory dump from DumpIt was corrupt. I've noticed that one or two times that old DumpIt may create corrupt memory dumps for some reason.

Anyway, please let me know if you have any enhancement suggestions or find any new bugs. I have some minor new features coming in the next few days that are almost ready (mainly driver parsing instead of loaded DLL's when looking at System "modules").

from memprocfs.

It should not be possible for my application to cause a BSOD. It's a user mode application that should at most crash itself upon any errors. A BSOD indicates some deeper problem - I suspect it may be with some interaction with the Dokany File System driver that I use. I'll check it out with the WinXP mem dump you suggested in a few hours.

1 - I'm interested in memory dumps on which the identification fails upon. If your dump does not contain sensitive data I'm interested in it. "unfortunately" my 17134 memory dumps are all working both with auto-detect and '-identify' - but systems are somewhat different. Regardless I'll try to investigate this.

One thing that I noticed on some systems though is that older DumpIt versions may generate corrupt memory dumps on some more recent Windows 10 systems. In my blog entry for the predecessor to this I use winpmem for this reason. ( https://blog.frizk.net/2018/03/memory-process-file-system.html ) I don't know if this is your situation though - especially since Volatility seems to work.

2 - x86 (32-bit) is not supported. I only tested the Memory Process File System on x64 Windows Vista and onwards. 32-bit versions won't work. This should not cause a BSOD though.

Please allow me to get back on this issue.

from memprocfs.

Update:
I've checked out the "Moyix's Fuzzy Hidden Process Sample Windows XP SP3 x86" image. Since it's a 32-bit (also PAE) image the Memory Process File System has no notition about this.

The topmost paging level in 32-bit (PAE) is similar enough to a 64-bit (IA-32e) PML4 so The Memory Process File System actually tries to mount it when I force the address -cr3 0x319000. The mounted result is totally useless though since all translations fail since it's not supported. It however does not result in a BSOD for me.

===

What Windows version are you running? Like exact version? (example: Version 10.0.17763.134). Also what version of Dokany are you using? Also did you install Dokany with the Bundle or separately?

from memprocfs.

Currently traveling in South America and have poor internet, so sharing the first memory dump (10gb) isn't feasible unfortunately.

Running:
Windows 10.0.17134.0
Dokany v1.2.0.1000 (from DokanSetup_redist.exe here: https://github.com/dokan-dev/dokany/releases/tag/v1.2.0.1000)

Tried uninstalling Dokan, re-downloading and re-installing Dokan from the same link and rebooting my machine. Still BSOD unfortunately.

I also tried using winpmem (imaged to aff4 without pagefile, then extracted raw dump from that) and get the same result.

The BSOD error presented is PAGE_FAULT_IN_NONPAGED_AREA.

from memprocfs.

Unfortunately I'm not able to replicate the BSOD problem.

I've installed your dokany version on a completely fresh 10.0.17134.1 (win10 64-bit both pro and enterprise) system (without any patches) and it works without any bluescreens.

I'm not able to find any media for "10.0.17134.0" unfortunately so I was only able to try on "10.0.17134.1". It works fine in both VirtualBox and Physical Hardware for me unfortunately :/

Anyway, I'm guessing the BSOD problem may be due to some bad interactions between Dokany and your system; or that it's something else with your system that is triggering it. My application should not by itself be able to bluescreen the computer. It's just a normal user-mode program. It has no kernel components on its own.

The separate issue of not being able to identify the memory dump from your win10 system is also interesting - but I would need a memory dump to look more into that.

from memprocfs.

No worries - I appreciate the effort in troubleshooting.

I'll have a bit more of a play and let you know if I have any success.

from memprocfs.

Thanks, also if you find the root cause of your BSODs it would be interesting to know. Also, that memory dump of yours.

Good Luck and hope you'll get it working :)

I'll leave this thread open for a while to see if there are any updates.

from memprocfs.

After analysing the crash dump in WinDbg, I identified reference to SysmonDrv.sys.
dmp_analysis.txt
To test, I uninstalled sysmon (I had the 64 bit version installed) and rebooted.

The BSOD issue appears to be resolved :)

Now for the actual Win10 memory dump, it is still not identified using 'identify', however now when I specify the DTB address from volatility in the -cr3 parameter, it mounts something. There seems to be an issue parsing the dump though, as only one process exists in M:\name\unknown_process-0. I imagine this is somewhat expected given the OS couldn't be identified. I also know you
can't troubleshoot this until I can share the dump :)

Regardless, I'm happy the BSOD issue is sorted. I'll try find another 64bit memory image online to test this out some more.

from memprocfs.

Aaaand final update - Whilst my raw dump using DumpIt did not work (as explained above), the raw extract of my .aff4 dump created with winpmem-2.1.post4.exe is successfully identified and works as expected.

Ready to rumble for tool testing! Would still be interesting to figure out why the DumpIt dump didn't work though.

from memprocfs.

I'm closing this issue since it seems to be fully resolved.

from memprocfs.