[RESOLVED] VB6 IDE Crashes

Whenever I Run from within the IDE, I get an error and VB6 closes. I can compile successfully. The compiled programs run successfully. I've uninstalled VB6, uninstalled MS updates, but nothing so far has helped. Throwing this out there before I reformat and start from scratch.

Windows 7 Pro x64
VB6 Professional with SP6

Event ID: 1000
Source: Application Error
Level: Error
Keywords: Classic
Task Category: (100)

Faulting application name: vb6.exe, version: 6.0.97.82, time stamp: 0x403acf6c
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x003b3534
Faulting process id: 0x1c28
Faulting application start time: 0x01d182bab843395b
Faulting application path: C:\Program Files (x86)\Microsoft Visual Studio\VB98\vb6.exe
Faulting module path: unknown
Report Id: 7b60a5ac-eeaf-11e5-b3f3-18037319c2c6

Have you tried other projects?
One of the more likely culprits for crashing the IDE is sub classing.
You may also want to disable any addins that you may be using and see if that changes things.

Quote:

---

Originally Posted by DataMiser

Have you tried other projects?
One of the more likely culprits for crashing the IDE is sub classing.
You may also want to disable any addins that you may be using and see if that changes things.

---

Yes, I've tried many different projects and all crash when run from within. I just tested with a very basic app. One button, calls a sub and displays a msgbox. Compiled and runs fine. Run from within, crashes.

What about addins? DO you have any in use? Have you tried disabling them?

Can you send the crash dump?

Quote:

---

Originally Posted by DataMiser

What about addins? DO you have any in use? Have you tried disabling them?

---

MZTools, MouseWheelFix. I've disabled both with no luck. I've also tried running without either installed.

Whats about API?

Quote:

---

Originally Posted by The trick

Can you send the crash dump?

---

I tried uploading the .dmp but the site states an invalid file type.

Quote:

---

Originally Posted by Greg0145

I tried uploading the .dmp but the site states an invalid file type.

---

Try to pack it to a zip archive.

Quote:

---

Originally Posted by The trick

Try to pack it to a zip archive.

---

Good call. Attached.

I don't think we know yet whether this is happening in a fresh install of vb6/the IDE or one that has worked ok in the past and is now giving trouble.

Quote:

---

Originally Posted by Magic Ink

I don't think we know yet whether this is happening in a fresh install of vb6/the IDE or one that has worked ok in the past and is now giving trouble.

---

I'd been using it on this install of Windows 7 for years with no trouble. Around November of last year this started and I've been working around it by compiling, running, and then fixing errors. This is not a good method and I'm at the point of either figuring out what is causing the crash or formatting and starting fresh. (I have uninstalled VB6 several times.)

It is always possible that you installed some 3rd party VB6 application that has a pathological setup program. Inno can be terrible for this, since safe usage requires that the packager know far more detail about proper deployment than most people do: it is unsafe by default.

My thought is that such a setup program forces an elevated run instead of relying on legacy scripted setup detection by Windows, and then it force-fits obsolete VB6 runtime components onto the system, replacing the ones that ship as part of Windows. Normally Windows will detect this and silently replace these files with the right ones afterward, having a little chuckle to itself.

However some people try to play "I'm still on Windows 95" by disabling UAC and other system safeguards, and always logging on with an account in the Administrators group. This ends up making Windows far more fragile than it might otherwise be.


These days Windows ships with VB6 runtime components tailored to the specific OS they ship with. You do not want to just plop some old generic redist versions or versions grabbed from the live system of another OS over the top of them. Under normal circumstances Windows will repair this, but a lot of VBers seem to think they know best and do absurd things like turning off UAC.


I'm not saying this is what happened to you, but clearly something did. If so... the only safe fix is to reinstall Windows from scratch.

It does sound to be an odd problem and is one that I have not saw. I've been using Vb5/6 pretty much every day now for about 20 years and I don't think i have had the IDE crash more than 1/2 dozen times over that period. The few times it did happen were always due to some error in my code and I have never had to take the uninstall<> reinstall route. Perhaps I am just lucky or maybe it is that I am careful but whatever the case I have had very solid reliability from VB5 and 6 on every machine they have been installed on over the years.

What is IndenterVB.dll at C:\Program Files (x86)\Office Automation\Smart Indenter\VB6\IndenterVB6.dll?
You should disable all addins: IndenterVB, VB6IDEMouseWheelAddin, MZTools.

Quote:

---

Originally Posted by The trick

What is IndenterVB.dll at C:\Program Files (x86)\Office Automation\Smart Indenter\VB6\IndenterVB6.dll?
You should disable all addins: IndenterVB, VB6IDEMouseWheelAddin, MZTools.

---

IndenterVB is part of MZTools. I've disabled and also tried without those addins installed. Still the same result.

It is a very odd problem. I've been using VB6 on this same machine for 6 years with no issue. I wish I knew what exactly happened last November that caused this issue. I made no modifications to VB6. Windows updates were installed but I've removed those that were installed during that time frame.

I'm going to carve out time to rebuild the PC, but thanks everyone for your input.

You had sent the crash dump when this addins were working, because they was being loaded during the crash. Address of crash doesn't correspond to any loaded module. Please attach the crash dump without those addins. Thanks.

Quote:

---

Originally Posted by The trick

You had sent the crash dump when this addins were working, because they was being loaded during the crash. Address of crash doesn't correspond to any loaded module. Please attach the crash dump without those addins. Thanks.

---

Dump attached with all addins disabled.

Ok. Thanks. I figure out the issue. VB6 allocates a dynamic part of code in the page that has got Read/Write access. If you have enabled DEP it will cause the access violation error.
Your program is being crashed (with ACCESS_VIOLATION error) on the dynamic part of code at the first instruction.
Attachment 136335
Perhaps this code doesn't execute because this page have RW access rights and you have enabled DEP. You should disable DEP.

Quote:

---

Originally Posted by The trick

Ok. Thanks. I figure out the issue. VB6 allocates a dynamic part of code in the page that has got Read/Write access. If you have enabled DEP it will cause the access violation error.
Your program is being crashed (with ACCESS_VIOLATION error) on the dynamic part of code at the first instruction.
Attachment 136335
Perhaps this code doesn't execute because this page have RW access rights and you have enabled DEP. You should disable DEP.

---

DEP was disabled and I checked the permissions of the folder I'm running this code from.

Quote:

---

Originally Posted by Greg0145

DEP was disabled

---

Anyway i explained the reason of crashing. There are some functions to control the DEP policy at runtime, maybe a library changes it at runtime to prevent execution. You can check it. Create an empty project and remove the Form from it. Add a standart module and insert sub main procedure:

Code:

---

Option Explicit

Sub Main
MsgBox "Test"
End Sub

---

Does it run? If no please attach the crash dump.

Quote:

---

Originally Posted by Greg0145

I checked the permissions of the folder I'm running this code from.

---

It does not matter in this case.

In post 3 the OP says a tiny very basic program crashes.
Wouldn't a dump from that be the best to check out ?

Rob
PS I have never installed add-ins for fear they would bite me one day ('KISS' is my middle name)

Quote:

---

Originally Posted by Bobbles

In post 3 the OP says a tiny very basic program crashes.
Wouldn't a dump from that be the best to check out ?

---

VB6 uses the dynamic code for calling of functions/methods. These codes call the ProcCallEngine/MethCallEngine function from VBA6.dll depending on the situation, and pass there the P-code. It doesn't matter which code OP is using. When it is being started an object instance it is calling MethCallEngine and when it is being started a standart module function like Sub Main it is calling ProcCallEngine. OP sent the crash dump when the startup object was form.

I removed the form and inserted a module, with the simple code shown below. Attached is crash dump from that attempt.

Option Explicit

Sub Main()
MsgBox "Test"
End Sub

Quote:

---

Originally Posted by Greg0145

I removed the form and inserted a module, with the simple code shown below.

---

As i said before the reason of crash is DEP. DEP is being turned on when the dynamic code is being performed.
Attachment 136351
ADDED:
For example, the previous crash happened when VB6 was calling the dynamic code with the MethCallEngine function:
Attachment 136357
The both crashes occur because it performs the code in the page that has the READ | WRITE permissions.

Quote:

---

Originally Posted by The trick

As i said before the reason of crash is DEP. DEP is being turned on when the dynamic code is being performed.
Attachment 136351
ADDED:
For example, the previous crash happened when VB6 was calling the dynamic code with the MethCallEngine function:
Attachment 136357
The both crashes occur because it performs the code in the page that has the READ | WRITE permissions.

---

After further Googling, I found that DEP is now controlled by bcdedit (new to me), which I should have checked after reading the previous recommendation. After disabling DEP I'm now able to Run within VB6.

Thank you very much for your assistance. I seriously cannot thank you enough!:)

I glad i've helped you!

Something seems very wrong, because disabling DEP is never a reasonable thing to do. People use VB6 all day long with DEP enabled and never have a problem.

This is because VB6 has a DEP exception, granted via a stock appcompat shim preinstalled with Windows:

Attachment 136361

Globally disabling DEP is not a good idea. Once more it sounds like this Windows install has been trashed and reinstalling from scratch is the best bet.

It is possible to create add-in with SetProcessDEPPolicy and run it at startup.

Quote:

---

Originally Posted by dilettante

Something seems very wrong, because disabling DEP is never a reasonable thing to do. People use VB6 all day long with DEP enabled and never have a problem.

This is because VB6 has a DEP exception, granted via a stock appcompat shim preinstalled with Windows:

Attachment 136361

Globally disabling DEP is not a good idea. Once more it sounds like this Windows install has been trashed and reinstalling from scratch is the best bet.

---

Completely agree. I'm currently trying to figure out what caused this to happen, and how to fix it. I've only noticed an issue with VB6, not other applications. The only thing that comes to mind is an installation of WebRoot security that caused us a good bit of grief last year. It's possible that it altered settings but I cannot be sure. I'll post when / if I find out what happened.

I was able to enable DEP with status OptOut, create a vb6.exe exception, and all is working fine. Granted, something is still off because as dilettante stated, plenty of users run VB6 without this issue. I'll continue to investigate what the root cause is and will update if and when found. But thanks to everyone again for the assistance.

My thanks also to everyone.

I had the exact same symptom as Greg0145 (with VB6 6.0.97.82 on 64-bit Windows 7).

I ran into this problem after having installed Microsoft's "EMET" security tool, with the option DEP set to "Always On". However, the cause-and-effect wasn't immediately obvious to me because in the lapse of many weeks before I ran VB6 on this machine, my system had been modified or updated by a number of other, more likely "suspects".

Your helpful thread enabled me to get VB6 working again. So many thanks!


It may help others if I detail here the 2 steps that are needed:

1. Set DEP (Data Execution Prevention) to OptOut by default.
To do that in EMET, you just choose "Application Opt Out".
If you're not running EMET, run CMD.EXE as administrator and use the "bcdedit" command-line tool to change the "boot configuration" as follows: bcdedit.exe /set {current} nx OptOut
In either case (EMET or bcdedit), a reboot is needed before step 2.

2. Define VB6.EXE as an exceptional opt-out.
You can do that in Windows' "Data Execution Prevention" settings dialogue, which you can reach either via Control Panel or via Computer.Properties, by choosing: Advanced System Settings - Performance Options - Data Execution Prevention.


By the way, this was not an EMET problem, as such. I still recommend running EMET to reinforce Windows security :-)

I am making and testing modifications to one of my applications within VB6. All too often after I have used some features in a subform and then close it, VB6 crashes.
I am running VB6.exe in a WinXP virtual PC (dedicated to VB6)(VMWare) on my Win7x64 host PC.

If you have this problem on WINDOWS 11, WIN11, maybe even Windows 10, Win10

goto

https://www.vbforums.com/showthread....ling-*any*-API

Cheers