VB6 - crashing the IDE

[Structural Integrity]

My boss pulled an old program out of his archive, and the bugger crashes the VB6 IDE.
Sometimes it happens when closing the program, sometimes it doesn't crash when closing the program, but then it crashes when closing the IDE itself.
It says: The instruction at 0x77fcc8e1referenced memory at 0x0131f261. The memory could not be written.
The memory it references is rather random. I've seen it reference at 64000 and 0, both for reading and writing.

My question is what could be causing the crash. I've done/seen quite a bit of weird stuff in VB the past few months, but crashing the entire IDE is rather new to me. So where should I be looking for the problem?

[JetLinus]

Well... Check Projects, References? Or Components... Something weird? Some outdated user-control?
Check the code for DLL or API stuff maybe?

Got VB5 at hand?
Or Windows 95 / 98 maybe?


Does the compiled exe crash?


[obligatory "SP6 installed?", sorry]

[Structural Integrity]

There are no outdated components as far as I know (nothing more outdated than VB6 atleast (Sorry, I have to mock VB every now and then )). The references are the same as in any other project I have here.

There are tonnes of DLL calls in the code. And guess what, I don't have any code of the DLL's.
And I'm a tad lost because the crash happens a different places at different times. Then it happens at startup, then it happens after the startup sequence, then it happens when I close the app, then it doesn't happen AT ALL.
And if the program doesn't crash, then the IDE crashes the moment I click the [X] in the upper right corner of the IDE.
This seems like a timing thing. I wouldn't be surprised if I found a timer somewhere that would wait until the loading sequence has ended before it does something. I found the exact same construction in another app here that caused a VB-error.

I managed to compile the exe, but some bugger license stuff keeps me from running it. And guess what, there isn't a license encoder around.

In which way would VB5 help me BTW?

Code like this makes me hate the fact that I chose programming as a profession .

[JetLinus]

I don't know HOW VB5 would help you, just give it a shot, you know.
There was a REAL annoying bug in out-of-the-box VB5: Some controls, one being Winsock, couldn't run. It said something about "you don't have the license file, go away please".

Maybe maybe Windows 98 would do the trick?
Or try setting Windows 98 compatibility mode for VB6.EXE?


Hmmm... :-/

[Structural Integrity]

And the error was found...

We take:
1 DLL with OS functions
1 DLL function that loads a set of registry keys in an array
1 static VB array dimmed at 20 indices
1 registry key with more than 20 items

- We take the VB app and load the DLL.
- Tell the DLL to load a all registry values in the static array with 20 indices
- Do not check if there's enough room in the array, and load MORE than 20 items
- Mix in some randomness to make it nice and difficult to track down, crashing here, then crashing there, then not crashing at all...

If the guy who programmed it wouldn't write me the paycheck every month I'd have kicked him under his arse.
And that's just ONE faulty construction in the many, many lines of code that this app counts .

[JetLinus]

Hm, shouldn't then VB throw an "index out of range" error anyway?

But that's usually my experience: The problem is ALWAYS something else, never "VB itself". Be it components, DLLs, just foreign stuff.
Even the Microsoft Internet Transfer Control used to be sooo buggy...


Cheers for sharing where the error was.
I hope it goes better in the future.

[Structural Integrity]

Originally Posted by JetLinus

Hm, shouldn't then VB throw an "index out of range" error anyway?

The DLL was written in C. So the DLL itself wouldn't throw an exception. It'd just write in unreserved memory. The damage had already been done even before VB could notice it. Windows would detect the memory violation and kill the VB IDE because that's the exe that caused it, it being the "virtual machine" of the application.

But that's usually my experience: The problem is ALWAYS something else, never "VB itself". Be it components, DLLs, just foreign stuff.
Even the Microsoft Internet Transfer Control used to be sooo buggy...

Well, I'm glad VB itself doesn't make its own IDE crash. I have more than enough worries only dealing with VB itself .

Cheers for sharing where the error was.

\o/

I hope it goes better in the future.

This is just the tip of the iceberg. And most of it probably isn't VB's fault, but the fault of the guy who wrote this app.