When Windows crashed and the BSOD appear, the CTM driver won’t be loaded and if the memory dump file is saved to disk, will mess the snapshots and all disk could be compromised.
I have manually change the folder to a non-CTM monitored one.
No dump file is saved, only the BSOD appears.
I think CTM is blocking it. Why?
[attachment deleted by admin]
Same goes for TrueCrypt and possibly also for Bitlocker, once the disk is crypted you’ll get a message in your eventlog at system startup that the crashdump driver could not be loaded because of this.
The part where the BSOD writes the dump is so low that the drivers arn’t even loaded.
So running disk encryption is the end of crashdumps…
I’m NOT talking about the startup BSOD. I’m talking a BSOD while Windows is running or even manually invoked. My system disk in NOT crypted, neither the disk where I’m saving the dump (a simple NTFS disk without CTM protection).
I’m not in a startup BSOD.
I’m not using disk encryption at startup.
CTM is NOT conflicting with TrueCrypted drivers.
The problem could even not being CTM but any other driver of any other application/hardware.
The problem seems that CTM is blocking the dump to be saved!
It does not matter at whish point the BSOD occurs. As soon as you see a BSOD, then windows did already jump to a state where all drivers will be deactive, meaning that CTM drivers will also be deactivated as soon as a BSOD occurs. Each write operation to a log file on a by CTM monitored partition would then be killing for the CTM snapshot structure. And at the next reboot chkdsk will probably be started, which will only make it worse. I can imagine that for this reason comodo dev team did disable the BSOD dump on purpose. Just to prevent nuking your file system.
If it occurs to a CTM protected partition. But it should not happen to another drive/partition.
If CTM prevents Windows to dump and to check the file system, it should do by itself. I can’t imagine the future of a product that is promising disk corruption, data loss, etc…!