0

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

Community
  • 1
  • 1
Brian
  • 25,523
  • 18
  • 82
  • 173
  • There is a slightly newer service pack for vb. I doubt it will fix this problem, but I recommend it anyway. http://www.microsoft.com/downloads/details.aspx?FamilyID=9EF9BF70-DFE1-42A1-A4C8-39718C7E381D&displaylang=en – George Mastros Dec 03 '08 at 16:52
  • I suspected someone would suggest that. I'd rather avoid that, though I think I might try testing it, just in case it miraculously does fix the issues. – Brian Dec 03 '08 at 17:11
  • I tried updating. It didn't help. – Brian Dec 03 '08 at 20:18
  • I have a similar problem with Crystal Reports XI in a VB6 app. Unpredictable, can't reproduce it (except by accident), etc. It seemed to start after I recompiled the code that uses Crystal Reports as an ActiveX DLL (it used to be an ActiveX EXE and apparently worked fine back then). – Mike Spross Dec 03 '08 at 22:40
  • However, I did find that changing the order in which I was destroying objects (Set obj = Nothing) made a big difference (the access violations still occurred, but become much less frequent). Maybe that will help? – Mike Spross Dec 03 '08 at 22:42
  • Maybe, but I was destroying them in the reverse order they were created. Actually, the program gets tons of access violations (without crashing) due to some really ugly memory manipulation code which is there to support a useless feature that was planned, then never completed due to its uselessness. – Brian Dec 05 '08 at 14:23

1 Answers1

0

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.

Brian
  • 25,523
  • 18
  • 82
  • 173