glDrawElements

Hi All,

I’m developing a OpenGl Program on win7 x86 32bit VM using GRID K2 GPU.

my program is like Pseudo code below

static BYTE* ptr = malloc(BUFFER_SIZE);

frame begin 

some code

for()
{
       1、modify the buffer of ptr pointer
       2、glVertextPointer(……,ptr);
       3、glDrawElement();
}

glSwapBuffer();

sometimes,A Write Memory Violation was throwed on the step 1 when i trying to modify the buffer of ptr pointer。

when i debug this issue,i found that glDrawElement call VirtualProtect for ptr pointer and making the buffer readonly.

how can i fix this issue or any tips for me

Any suggestions greatly appreciated!
Thanks

these days, i found that if ptr is static memory region, the Write Memory Violation can not be throwed.

It’s really werid.

Any suggestions greatly appreciated!
Thanks

when i use debug tools ,i found it show a message “__wglImpWWVirtualAddWatch”.

so……

what’s the meaning of “__wglImpWWVirtualAddWatch”? how to triger this function?

Any suggestions greatly appreciated!
Thanks

Hi Xiaolang,

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…

Regards

1 Like

Thanks for posting this.

We’ve been tracking down a ReadFIle issue for almost a year now. Microsoft support directed us to find what code (ours or 3rd party) was calling VirtualProtect (PAGE_READONLY) when one of our Devs found your comment. After switching to the other nVidia profile, we haven’t been able to repro our issue.

We also believe that another longstanding issue of ours is caused by this. In the other issue, it’s WSARecv (in gRPC library) that is failing.

If you don’t mind my asking … what “Windows API-Monitor” did you use to find this out?

Thanks

Hi Christopher,

I used the Rohitab API-Monitor (API Monitor: Spy on API Calls and COM Interfaces (Freeware 32-bit and 64-bit Versions!) | rohitab.com).

It is very likely that the remote procedure call functions use the ReadFile-function to transmit the stream.

But I think that other functions of the WinAPI also directly check the protection flags of the provided memory before writing to it…

Best regards,
Dennis