VB6 keeps crashing on me!

[aylmerj]

Can anybody help?

I'm developing a VB6 application which involves a lot of matrix manipulation (loading a matrix using bits of other arrays, inverting the matrix, &c.) - but progress is slow, because VB6 keeps crashing at different points when I try to run the application. Sometimes it asks me to send an error report to microsoft (I must have sent over 100 in the past week), but sometimes it just quits without saying anything.

I'm quite prepared to believe that this is because I'm overwriting some part of memory that I shouldn't be accessing (I'm using CopyMemory quite a lot to load the matrix) - but how do I find out if or where I am doing this? The program itself seems to work exactly as I would expect, and I can make an .exe file from it - but this also crashes randomly.

I'm using XP for this work - if I try to run the application under ME (either from within VB6 or as an .exe file) it crashes immediately.

Can anybody give me any guidance as to how to diagnose this? I'd be most grateful! I've attached an .exe file which shows the problem, but would gladly make the source code available to anyone who is willing to wade through it...PM3.exe

[jdoe]

You can put breakpoints in your code and parse lines step by step with F8.

If you are using CopyMemory API, without having see the source code, I would say that it must be that call that make VB6 to crash (it is a common problem).

Put a breakpoint at each CopyMemory call and when you press F8 and it crash then have found the problem... or one of them.

This is how I declare CopyMemory...

Public Declare Sub CopyMemory Lib "kernel32.dll" _
	Alias "RtlMoveMemory" ( _
	ByRef r_Destination As Any, _
	ByRef r_Source As Any, _
	ByVal v_Length As Long)

Edited April 5, 2006 by jdoe

[LLXX]

Hmm.... IPF in the kernel.

PM3 caused an invalid page fault in
module KERNEL32.DLL at 016f:bff7a138.
Registers:
EAX=0be30768 CS=016f EIP=bff7a138 EFLGS=00010216
EBX=004683f4 SS=0177 ESP=0064f048 EBP=0064f07c
ECX=bfe6a09d DS=0177 ESI=004682bc FS=1887
EDX=d11b6e38 ES=0177 EDI=0be308a0 GS=0000
Bytes at CS:EIP:
89 51 08 8b 53 08 8b 43 04 89 42 04 8d 93 0b 10 
Stack dump:
0064f07c 004682c4 00420000 0042002c bff7b31d 00420000 004682bc 00000138 00000200 bff94645 0064f178 00000000 004682bc 0064f1d4 7ff214db 00420000

Certainly looks like CopyMemory caused it.

VB isn't really designed for such intensive tasks as matrix manipulation... it is Visual Basic after all

[aylmerj]

Thank you both very much for your confirmation of my suspicions, and your guidance.

The trouble is, I don't think the fault in my code causes a problem the instant it executes! The program van run round a near-identical cycle (with slightly different numerical values in the variables) several hundred times - and then Visual Studio crashes when the program is manually stopped.

I'm trying to use Debug.Print to store the information that might help me track down the problem - but how can I see what addresses CopyMemory is actually writing to, and how would I know if one of them was illegal?

Thanks again...

[LLXX]

It might be an off-by-one error, which can gradually overwrite addresses until it reaches the end of the page.

What happens if you decrease the number of times the main loop is run to a very small number e.g. 5-10 times only? Does it still crash or not?

[healydj]

Get a copy of Matthew Curland's Advanced Visual Basic 6. His VBoost component sounds like what you need. It's a free download from his web site for owners of the book.

Getting any support from Microsoft for VB6 is a daunting task these days. Curland worked for them, and wrote quite a bit for the VB Programmers' Journal pre-.NET. If you are going to mess with CopyMemory, this book is a must-have.

On pages 8-9, Curland notes: "Be incredibly wary of the IDE's Stop button and the End statement in code....An abrupt End to a program bypasses most termination code, potentially leaving VB in a bad state. You won't always crash if you hit the Stop button, but you will crash often enough that you'll stop doing it. Turning off Compile on Demand in the General tab of the Tools/Options dialog will minimize the need to push the Stop button."

[aylmerj]

Thank you both!

I now suspect that many of my problems arise from the way(s) that I'm terminating the application. Many of the errors seem to occur at this point, now (and I had been thinking that I was fouling up the exit sequence by doing something illegal during the main execution). But that's not the whole story - I now have code which monitors every address passed to CopyMemory, yet the program can still crash after executing for a minute or two, without the monitor picking up any suspicious addresses...

Matthew Curland's book sounds like a good idea - and probably cheaper than investing in VB2005, at this point...

[LLXX]

I don't think it's the exit, since it crashes when I press the button to start it.

without the monitor picking up any suspicious addresses...

How do you know if it is suspicious address? It's actually quite hard to determine if it's overwriting something else unless it's writing to kernelspace or null addresses.

Perhaps you should run it under Win98. It crashes almost immediately after I start it. The NT-series of OSs are more resilient to memory corruption, which is why it seems to work for a while before crashing. In this way they hide flaws and make debugging a bit harder.

[healydj]

While you're waiting for your copy of Curland, here are a couple of points he makes that might be relevant:

1) On page 22 - 23, he discusses issues with arrays declared at module level. Apparently there are issues re "unwanted memory destruction". One of the work-arounds is to lob your arrays into class modules. Per Curland: "Always clear the array variable in your Class_Terminate, calling Erase to free referenced pointer types if needed." A module, by definition, does not have a Terminate event.

2) On page 149, he points out a problem that will drive you nuts if you're unaware of what's going on. "If you use a CopyMemory call declared in VB, any string parameters undergo UNICODE/ANSI translation during the API call." If you're referencing structures in your code, this one will bite you - hard!

Curland's VBoost component has its own methodology for copying memory. It's unfortunate the book was published just as .NET was taking centre stage, and thus never received the accolades it surely would have garnered had VB6 remained Microsoft's flagship. The book is the magnum opus of a genius, and contains much wisdom that pertains to coders in any language.

[HyperHacker]

FYI, I don't know if this applies to VB, but I code in C and when my program just closes for no apparent reason, nearly every time it's due to a stack overflow.

[aylmerj]

Thanks, Hyperhacker!

I have had a few stack overflows, as well - but VB always (as far as I can see) seems to report these properly - so I don't think that's the problem here.

This project was a conversion from Fortran - so instead of trying to work with big arrays of real numbers, I'm now breaking it all down into Types, each containing lots of little 3-element vectors. It's a long job, but the new code runs much more reliably - and goes about twice as fast, too...