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.
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.
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.
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.
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.
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.
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.
Perhaps this code doesn't execute because this page have RW access rights and you have enabled DEP. You should disable DEP.
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.
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.
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.
Originally Posted by Greg0145
I checked the permissions of the folder I'm running this code from.
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.
As i said before the reason of crash is DEP. DEP is being turned on when the dynamic code is being performed.
ADDED:
For example, the previous crash happened when VB6 was calling the dynamic code with the MethCallEngine function:
The both crashes occur because it performs the code in the page that has the READ | WRITE permissions.
Last edited by The trick; Mar 22nd, 2016 at 11:27 AM.
As i said before the reason of crash is DEP. DEP is being turned on when the dynamic code is being performed.
ADDED:
For example, the previous crash happened when VB6 was calling the dynamic code with the MethCallEngine function:
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!
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:
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.
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:
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.
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.
[RESOLVED] VB6 IDE Crashes
Reply With Quote
Originally Posted by DataMiser
Re: VB6 IDE Crashes
