ole32.dll causes GPF. How to interpret DebugDiag report?

Answer 1

GPF on exit is usually caused by wrong deinitialization sequence. For example, the following could have happened: some code that releases all objects has been called already and now you have a dangling pointer and the code currently executing is trying to release the same object. Since the object is no longer there you get a GPF.

Such situations are usually hard to debug. What you need is a dedicated deinitialization where you would disconnect, finalize, flush, close, etc. all objects that you initialized while running the program. In most cases all you need is to just set the pointet to the object to Nothing - built-in resource management will have the object properly deinitialized. You have to execute this code before the whole program termination starts - somewhere like when closing the main window.

Answer 2

I've found that in these cases, it's very often objects that are referenced by VB Forms. If you set the Form's variable to Nothing in the Unload event, and make sure you either call Unload after using the form, or before the application closes, then the GPF goes away.

Answer 3

You could try using John Robbins' Crashfinder to see whether the hex address (0x04246c81) corresponds to any of your own code. Might give you a clue to which objects are involved. Build the app with debugging info to create a PDB. Then reproduce the error again with the new app (as the PDB info will change the hex address in the exe).

The Crashfinder.exe is in this self-extracting ZIP. Do File-New to create a new project, then Edit-Add Image to load your exe. Then Edit-Find Crash and type in the new hex address. It will tell you the source file and routine corresponding to the hex address (if it is in your own code).