I found out, that Nvidia makes a hidden “copy-on-write optimization” with the memory you provide to the driver.
This optimization marks the memory-pages your memory intersect with as read-only (WinAPI-Function “VirtualProtect” parameter flNewProtect “PAGE_READONLY”).
The page size is 4096 bytes, so it is not unusual you have some intersections with other memory in the same pages.
When you try to write to this memory, NVidia catches the signal, copies the data and releases the write protection.
But this optimization can lead to huge problems, because when other memory blocks in the process intersect with one of these pages, some WinAPI functions that check for write protection will fail (e.g. when the buffer you give to “ReadFile” is write protected by Nvidia)!
Our customers had mysterios crushed binary-files over years, and we could not find a reason for this in our source code.
And we have many other problems with “hanging” threads, when this COW-optimization is active.
The nasty thing is, that this optimization will only be activated, when you start the program without an attached debugger!
So the most of us will never find the reason for their problems…
I found it after many month, by using a Windows API-Monitor attached to my process.
(it must be attached after the initialization of the graphics!).
One solution for this is to select the “Workstation App - Dynamic Streaming” profile in the Nvidia Control Panel. In this profile, the “optimization” is deactivated.
But most of our customers are using the “Base Profile”, which is the default.
Perhaps Nvidia assumes that the users of their graphic adapters just playing online games, so this doesn’t matter.
But our customers driving huge CNC-Machines by the programs we calculate with our CAD/CAM Software.
And it can be really dangerous to life, if the programs we produce for these machines contain rubbish because of failed file-reads…