BSOD on Windows 10 with VSM

[michaelafry]

I have encountered a number of memory capture tools that fail and trigger a BSOD on windows 10. There is a really good article as to why here https://df-stream.com/2017/08/memory-acquisition-and-virtual-secure/.

When I tried to use this in our environment I received this.

[vivianezw]

Yep. Already on my way.
Also see duplicate #9 .

[anudedeus]

Hi Viviane,
I think you and Mike are doing a great job keeping Winpmem going, thank you very much for this.
Regarding the code, the last commit I can see was done 8 days ago, and there's an asset Winpmem.rc2.exe for download, but the text on the releases page talks about RC1 only.
Does rc2 contain the fix for this BSOD issue, and is there an ETA (roughly) for a post-rc2 (rc3 or final) version?

[vivianezw]

As to my knowledge, rc2 contains the signed driver, which BSODs (it might not if using the PTE method).

The BSOD-free version is here: https://github.com/Velocidex/WinPmem/files/5386510/winpmem_testsigned_15_okt_2020_2.zip
PW: betatest

but it ist testsigned only. We are waiting for you to test it!

The problem is the signing: we can't sign each freshly compiled version. Scudette has to ask other people for external help. (Microsoft's signing policy.)

Worse: in Feb - April, it will not be possible to sign drivers anymore, because:
All your driver code are belong to us says Microsoft

and OSR's reaction read here:
OSR calls for help

For the future it means (if OSR fails with its call for help):

1. Scudette signs the very last signed winpmem driver before this deadline. It ceases to be usable after some years, when the certificate expires. After that, no signed drivers anymore.
2. Get used to testsigned drivers.

[scudette]

Just to clarify the rc2 solves the BSOD in the default setting (which is the PTE method). There is probably no reason for anyone to switch to the other methods deliberately but Vivian committed the fix to those methods just in case anyway.

Please report any issues with the rc2.

[scudette]

Regarding the issue Viviane refers to with the difficulty of signing going forward - it is a real issue and these kinds of policies were proposed by Microsoft in the past but they always backtracked over them when people complained.

Regardless it seems that once the driver is signed and timestamped it should continue working into the future (even past the policy change date). See this quote from the policy

https://docs.microsoft.com/en-us/windows-hardware/drivers/install/deprecation-of-software-publisher-certificates-and-commercial-release-certificates#what-will-happen-to-my-existing-signed-driver-packages

The issue is only with us being able to release a bugfix or adapt the driver to a new kernel release - which this project does so rarely it might not be a real problem (we used the previous signed driver for about 4 years and only needed to re-release it recently).

From reading the policy document it appears that attenstation signing will continue working for Win10 - it is only an issue of running on old windows versions. Hopefully by the time we have an issue, those older windows versions are not going to be an issue anyway.