Hello!
I'm kinda ashamed to ask this question, but:
In one of my projects, during the cleanup-routine, glDeleteTextures() throws the exception mentioned above IF running it from within Visual Studio - that is no glError is generated nor does the program crash or something if run outside the IDE. If simply clicking "continue" everything seems to go well. Note the above is a windows-exception, not a glError.
I've spent some time trying to reproduce it in test-cases but this does not seem so easy. Even when calling DeleteTextures with trash-values nothing special happens. The strange thing is that quite a few textures get deleted during the cleanup and only one or two trigger that exception, so I doubt I'm doing something wrong methodically. I've tried to verify the texture-ids passed to glDeleteTextures: I've checked for double-ids and I even drew each texture in full-screen before calling the cleanup-routine to have a look if the ids are okay: They are all there.
I've to say I don't have the slightest idea what could trigger the exception.
Does anyone have an idea?

Before as destroying the window would destroy the rendering-context the textures live in I guess. The exception popped up once or twice again since it seemed to be gone. This is quite mysterious. Note that I did come to writing a cleanup routine because of the very same exception being thrown by the driver when simply calling exit() or destroying the rendering context without deleting anything myself. My guess was the OS would handle the cleanup correctly (and it did, I guess - the exception doesn't do anything outside the IDE).

Dunno - what do you mean? Is it possible that the DeleteTextures-call triggers something else that leads to the exception (like the driver shifting around stuff because some mem got freed)? The exception appears in the controlled cleanup-Routine. This is what is making me scratching my head.

Is it possible that the DeleteTextures-call triggers something else that leads to the exception.

Unlikely.

HANDLE in this exception is a Windows API data type, and the fact that the exception is being thrown with seeming randomness indicates that the problem is not at the glDeleteTextures call but somewhere else. One thing that can cause this is a bad pointer leading to a corrupted return address leading to execution jumping into the middle of a function where it has no business being.

That won't lead anywhere I guess. Despite the fact that it would likely take 10000 "continue"-clicks to catch the exception, now that it suddenly seems to have fixed itself. No - those pointers are all right. If something was wrong context-wise I'd have catched that later on.