VB6 Program Crashing: Part 2. Advice on fixing Access Violation (0xC00000005)

Question

Related to this question. Any advice on fixing the problem below?

After a lot of experimentation with the program, I have discovered several things.

1. It crashes relatively consistently (90% of the time or so) upon running the line of code, Set Message = New CAPICOM.EncryptedData. Note that the line above this is merely Dim Message As CAPICOM.EncryptedData.

2. The function that makes that call does not crash when called earlier in the program's execution. Binary search for error does not work to find the problem, since calling the function in some places mysteriously, unreliably prevents the bug from happening. Sometimes rebuilding the program seems to impact if the bug shows up. Yes, it is a heisenbug. The same issues apply with temporal binary search for error. Spending 5 hours comparing two versions of the program only to discover that both versions have the bug even though only one of them is currently showing the symptoms is not very productive.

3. The crash is due to an access violation 0xC00000005

4. Running WinDbg (the windows debugger) shows that there is only one line of code which reads this memory location, LoadPicture(szTmpBMP). It is called at the end of a scary function which grabs the picture out of a resource and sticks it in a temp file. I was scared enough of this function that, for the sake of testing, I replaced it with a call to LoadPicture("testcra.bmp"), then didn't call the scary resource function for that bitmap. This did not help. Removing this call to loadpicture entirely also did not help, though the debugger could no longer find any points where the affected memory was being read, and the affected memory was no longer at the same location. This testing was done on a VM, so some memory reads are not necessarily going to be visible to the debugger.

5. Everything works perfectly on Vista (both my local machine and a Vista VM). The access violation only occurs on XP.

6. I'm using VB6 Version 8176, 6.0.8169

Answer 1

My current solution, which works, is to create all my capicom objects early, and never to create new instances of capicom.encrypteddata beyond the first. This works, but it is unlikely that the underlying problem was actually fixed.