VB6 app does not run on SOME Windows 7 machines but works fine on others

The problem is probably related to running the application on Win 7 64-bit.
You should try to set the application to run in compatability mode (set the exe properties to run in Win XP compatability mode).
You should also make sure the application is not installed in the "program files" and "program files (x86)" folders.

The program is installed in the program files (x86) folder tree...

I did indeed try to set the program to Windows XP compatibility mode... tried SP3 and SP2.... both the same result.... same error occurs... and program does not run.

Did you try installing the application in another folder and setting the security settings of the folder ? Grant full access permisions to the current user on the application folder and all sub folders.

Before I get on to your problem, just a question myself if I may....

I am about to change from XP to Win 7 and I have a lot of applications which I have written in VB6 and which I may still need to maintain (although new apps are now being written in Visual Studio 2010).

Does the actual VB6 programming environment still work under Windows 7?

Now, in answer to your question, it may have something to do with the DLLs
your program uses. You may have different versions on different machines, hence the problem on some machines and not on others.

May I suggest that you investigate all the "References" and "Components" you have in your app, go to a Windows 7 machine that DOES run the app. OK, and copy all these references and components from the Windows 7 machine to a flashdrive, copy those collected files back onto your development machine,
(might be an idea to nackup the existing DLLs etc. first) then create a new "Installation" package for your program (after a full compile)

Instruct anyone who is installing the newly created application package on a windows 7 machine to OVERRIDE any messages about "already existsing" files on the Windows 7 machine, preferring the files in your installation package to those already existing on the windows 7 machine.

If that works and the application then runs on a Windows 7 machine on which it did not previously run,  then you know that the reason some fall over is the different versions of the references or components.

That is about all I can think of, seeing how you have tested "compatability" mode already with no success.

It will be interesting to see what reullt you get. Anyway, please let me know if VB6 compiler runs OK on Windows 7.

Cheers
Chris (craisin)
Melbourne-Australia

I once had trouble with the process PIDs that were too big on newer computers running tons of processes. The PIDs didn't fit Integer type variables and I had to change these variables into Long types. You may be facing the same kind of issue... you will need the sources and the debugger.

craisin... I have been programming a long time... and use Lindersoft setup builder install tool... but I don't know how to check the references etc. on the win 7 machine... is there a way to do that???  if so how?

Derdonn, I hear what you are saying but need more info... how would I check that this is an issue...  I do not think I create a prociess PID out of my app at least not in my code... not spinning off any other processes that I'm aware of... how would I check this???  Diagnose it?  Then find the variables at issue?

You would have to check the references by looking at the installation file which was used when the program was installed on the Windows 7 machine.

If you can isolate which installation file was used, then you would run that file on a windows XP machine on which the program is NOT already installed, and then install that program on the XP machine, carefully noting any messages about "overwrite" etc. (and accept them).

Then you would install VB6 on that same machine  and go into your Lindersoft
setup builder to investigate what references you have used.

That will then give you the package details for all future Windows 7 installation files.

An alternative (the quick fix) is to obtain the setup program that was used on a PC running windows 7 on which it WORKS and simnply install again the program from that package on a Windows 7 machine on which the program does NOT work, advising the machine to OVERWRITE any files which are "newer" on the host machine.  (Perhaps doing an "uninstall" before installing again would be a good idea).

If this fails, then it must be an "environment" issue between the PCs running windows 7. Ask yourself, how do these machinesdiffer in their setup? What "background" programs are running on each of the different ,machines?Compare the DLL files used (dates, times etc.) A bit tedious, I know!

Anyway, do you have an answer for me? Does VB6 actually run as a programming environment on Windows 7 (can I create a new program using VB6 by running VB6 on a W7 machine?)

Cheers
Chris
(craisin)

RE: Running VB6 in Windows 7
craisin, sorry for the delay... I was at a conference last Thurs and Fri and am just now coming up for air....

I have not tried running VB6 on a windows 7 machine.  I am still using Windows XP Pro as my main work machine for all of my work including development in VB6.   I do know one thing... you can use windows virtual pc on a windows 7 machine to install Windows XP inside the virtual pc and then in turn install VB6 inside there.....  so if you are just wanting a newer faster machine but want to still do VB6 development... consider the above (if VB6 does not run)....

I would consider going into Google and seeing what you can do... on this page I found several recommending virtual pc approach... and others mentioned maybe they could get it running in windows 7....  here is the page I found:

http://social.msdn.microsoft.com/Forums/en-US/vbgeneral/thread/b1340d04-220b-4e20-a827-d9c0bc8dd6c5/

RE: Checking references

Not sure exactly what you are saying... I have the installer file, built it myself in setup builder... the SAME install file works fine on all versions of windows.  I do not have a separate installer for Windows 7.

Are you referring to the uninstall log file to track references?

Or perhaps is there a utility that "watches" everything installed and creates a log of all the versions and results?

Or perhaps I can just run down all the DLL and OCX files and check the windows 7 machine that works vs. the one that doesn't work... as you mention maybe there are 64-bit versions that are on the one that doesn't work that are not compatible with my app???

Another recent clue... had 2 people install on Windows 7 Ultimate and the app does not run on either one... so maybe things are even tighter on Ultimate????

Upon investigation, I have a feeling your problem are not related to the VB application, but rather to the environment on particular Windows 7 machines.

Perform the following search in your browser and look at all the thousands of people reporting the same problem over a variety of applications (some in browsers, others in C++ applications etc.)

     http://au.search.yahoo.com/search?q=application+has+stopped+working

It seems to boil down to the setup of the particular W7 machines and how they interact with each application.

That is not to say that having a missing OCX/DLL is not the problem. It seems Windows 7 may act differently to XP is reporting problems. From some posts there is a suggestion that when Windows 7 finds a problem for which it has no error message, it simply says "Application has stopped working" rather than saying "Unknown Error".

It could be that a program running on one W7 machine at the same time as yours has caused a problem, again crashing your program (perhaps "file already in use") but producing the generic error message from W7.

Have you found that a fresh installation of you program on a Windows 7 machine
has that error straight away, or does it appear after a certain elapse of time and operations? In other words, are there machines where the program worked but then suddenly didn't?

I had a recent problem on my XP machine where a "Microsoft automatic update"
caused one application to always fail because a driver it uses no longer works under the updated XP system. Could th W7 machines received updates which caused problems with drivers which your program uses?

A lot of investigation needs to be made.

In summary, I don't think your program is at fault.It is an environment issue on the Windows 7 machines. Since your program works on some W7 machines and not on others, and you use the same installation program for your EXE, then you need to see what differences lie on these W7 machines, either via the OCX and DLL files used by your program, drivers used by your program, or other programs running concurrently with your program.

You need to make this comparison between one W7 machine which works OK, and one which does not.

That is about all I can think of , mate!
:-)

Cheers
Chris (craisin)
Melbourne-Australia

craisin,

I have found that on some windows 7 machines the program DID work and then one day it did not... thus I suspected automatic update causing the problem, or an antivirus or antispyware program....

On my own windows 7 64bit laptop... the program DOES work and has ALWAYS worked... so I have been methodically adding the MS updates.... to see if one in particular is causing the problem... I had over 100 updates unapplied... am down to the last handful and it still works fine on my own windows 7 machine....

My problem is client does not want to hear "its your machine" all they know is program does not run so it is our job to make it work.....  

This is indeed driving me crazy.... I will find a win7 machine it does not work on and check every dll and ocx to see if installed and also if same version and date etc.  and also continue applying MS updates to own machine to see if one breaks it....

Thanks for the ideas though....  -T

It seems the updates by Microsoft are not the problem, then.

Try re-installing your program on a Win 7 machine that does NOT currently work, ensuring that you OVERWRITE any DLL or OCX or other file that the installation program flags as "already exists or is newer" on the Win 7 machine. After installation, make sure you re-boot the Win 7 machine.

If that works, then it means that on the Win 7 machines that do NOT work, they are running an incompatible DLL/OCX (or are missing one).

Quite a problem!

Cheers
Chris (craisin)

By the way, did you read a lot of the links I referenced under the search link above? Never lose track of the fact that it might be the environment of particular W7 machines. In that case you would have to investigate what is running in the background of a "working" W7 machine as against a "non-working" W7 machine,
as well as memory allocation, virus checkers etc.

Good luck

Cheers
Chris

How are things progressing?

Cheers
Chris

On the Windows 7 64 bit laptop where the app DOES work... I managed to install every single Microsoft update in the queue..... the program still runs fine.  So I'm guessing it is not something MS had done that now is hammering the app.

Now I will have to compare environments with a machine it is not working on.... the problem is they are customer's machines so I would have to get them to let me investigate.  And I would kind of need to know what I am looking for.  Previously when first encountered I turn off all anti-virus, anti spyware, firewalls etc. DEP, and UAC.... none of those helped.... so it must be something with the DLLs or something....

OK....I'll stand by while you continue your investigations! Have fun!  :-)

I found another customer with this problem.... this time after turning off Norton, DEP etc. and getting no results ... I went thru the controls, ocx and dlls installed for our program....  I found that they are installed into the SysWOW64 directory.  This is also true on the Windows 7 system where our app DOES work... so I'm guessing that is not the problem.

I did find one control with a different version... comdlg32.ocx but it was more recent than the one in our installer.... the one on the working win7 system also has a more recent version.

Next thought is to create a debug version and use either log statements or print out to see in DebugView what is going on.....

I must say you seem like quite an expert "debugger" !    :-)

Remember to look at memory allocations and how much memory is free on machines that work viz a viz those that don't (just in case lack of memory may be a problem). If memory may be the problem you might find some machines that work sometimes and not others depending what is running in the background.

Another thing is, on machines that DON'T work, is there a program running at the same time as your program tries to run but on the machines that DO work such program is NOT running alongside (not very clear but I hope you get my drift).
There may be a program that is incompatible with yours for certain reasons (calls to the same modules which are not allowed etc.)

I await with interest your adventure! (a little like raiders of the lost ark!)  :-)

Cheers
Chris

I did not think of killing every program on the computer.... but with client's permission I will try that next time... for now I have created this debug version that will log statements to a file trying to narrow down the section of code that might be failing.....

Perhaps it is something with the registry or some uncaught file exception....  at this point I have no idea but the code logging might help... I see the first screen outline coming up as a ghost and then the app is hammered so I think some of the code does execute before it crashes...

i will let you know and thanks for your input, craisin!

Hi craisin,

This link is for you. It worked great on my Win7 Ultimate 64-bit Install

http://www.fortypoundhead.com/showcontent.asp?artid=20502

Thanks ebad-it....Very interesting post which will come in handy. :-)

I am trying to stick to VB.Net now in new developments, but having the instructions on the best approach to installing VB6 on Windows 7
(in case of need)  is a handy bit of information.

Of course, it does not help answer our current problem (which is working out why a certain VB6 application ruins on some Windows 7 machines and not on others), but it is a gem of info worth retaining anyway. Thanks again.

Torrid-33, the error message "Program has stopped working" on a Windows-7 machine CAN be caused by the program not having correct "Access" rights when performing certain activities. As a check on this, run the program on a Windows-7 machine on which the program currently does not run but do so when logged on  as a user designated as an "Administrator" (an alternative to this, although not as desirable, is turning off Windows 7's UAC (User Account Control) before running the program. Perhaps certain actions by your program require Administrator rights in order to run. (Some comments are made about UAC in the link kindly supplied by "ebad-it" in the previous posting 37215801, above)

So, back to you "torrid-33" for your James Bond attack on tracking this down!
When you "kill" programs, do them one at a time so you can isolate which program is causing the problem. (i.e. Kill one.....see if VB6 program runs....if not, kill the next one, re-run VB6 program to see if it then runs....etc.) As soon as it DOES run then the last program you "killed" is the one causing the problem.
Of course you then still have the problem (once you find the "rogue" program which is stopping things) of ascertaining whether a program previously "killed" ALSO causes the problem (i.e. more than one program is causing the problem).
Oh, well....  :-(

As one of our politicians said many years ago "Life wasn't meant to be easy"
(Malcolm Fraser...ex-Prime-Minister....See very interesting posting on him on:
http://en.wikipedia.org/wiki/Malcolm_Fraser)

Cheers
Chris (craisin)

Does your program use dll's or ocx files, if so have you checked to see if they are in c:\windows\sysWOW64 and registered there.  Maybe some of the other PC's had the dll's or OCX files already.  Just a thought

Good thinking ebad-it....

I gather the VB program we are looking at is 32 bit, Torrid333.

If the DLLs it is using are 64 bit I am not sure if that would work.

I know a 32 bit program will run on a 64 bit machine (using 32 bit DLLs), but
I would think a 32 bit program cannot use 64 bit DLL/OCX's.

Cheers
Chris

A new update... got some time on customer's machine today... he was very generous... got to spend a bout 2 hrs on there... tried everything under the sun.... disabled all the AV and anti-spyware... killed as many programs as we could find to rule out conflicts with other programs...

Checked that all the controls were in the C:\Windows\SysWOW64 directory and they were.  I found one control that I tried to register MSCOMCTL.ocx and it failed ... but then I wrote a .bat file and included every component and did "Run as Administrator"... they all registered successfully but yet program still crashes.

I created a debug version of my software where I wrote out debug statements to a file... proved that it properly executed all the code up until it tries to show the main window....

frmWorksheet2005.show

I had a log statement inside the form Load routine of frmWorksheet2005 which NEVER got written... so when it tries to load that form the app is crashing... would that mean it is something with the controls?

Given in VB6 you have "references" and "components" in the project... how do I tell for sure what things need to be installed?  Now keep in mind the app runs on all versions of windows including most Windows 7 machines... found 4 machines it does not run on....  For example, the project references a type lib subclassingthunk.tlb .. it also references SSubTimer6.dll scrun.dll and MSHTML.TLB .... none of those get installed by my installer... but are referenced inside my VB6 project... could those be an issue?

Last thing I can think of is that the form uses ctxHook menu to color the menus and put images to left of some items....  maybe it is something with that that is crashing it... I could try removing that perhaps and going to regular menu.

Any additional thoughts appreciated.

Add-on.... after writing that I started thinking the hook menu was causing the problem....  so I copied my project and stripped it out of the software.... recompiled.... got customer to let me test it and voila it still crashed.... so it is not the Hook menu....

BTW inside form load I have an immediate On error goto statement that goes to an error handler.... that never gets triggered.... Windows does not even throw up a message saying the app "has stopped working and had to be closed"... now I get nothing.... checked TAsk Manager and it was not running... double checked the process list too... not there...

Same debug exe runs fine on my Windows XP machine... goes into main window just fine.

Also did I mention I installed DebugView on his computer but no messages showed up in it...

OK - it looks to me that it is definately the missing files
   type lib
  subclassingthunk.tlb
  SSubTimer6.dll
  scrun.dll
  and MSHTML.TLB

You should be able to specifically add these to your installation program during the time you build the distribution files. What program do you use to build the installer?

The "on error" will not work with these sorts of errors.

Make sure you install the versions used in the applications that DO run on Windows 7 machines, so I suggest that you copy these files from a Windows 7 machine on which the application DOES run and include them in your installation package (designating that they are to be stored in the applicable folder in which you found them, ...for exapmle "C:\Windows\System or C:\Windows\System32

Cheers
Chris

Oops, ignore mention of the file "type.lib" (no such lib).

I meant "the type libs:
     subclassingthunk.tlb and mshtml.tlb
and dlls:
     ssubtimer6.dll and scrun.dll

Cheers
Chris



   

Well I looked at the windows 7 working machine in our office where we don't have this issue...
subclassing tlb and the ssubtmr6.dll are NOT installed on that machine so that's not the issue.

I went thru and listed every control and version on the WORKING machine... and then went on customers machine and compared each one one by one... tedious...

Everything matched except:

comdlg32.ocx  which had a newer version

and mscomctl.ocx which he had an older version.

I then tweaked our installer to force an "always update" to install our versions... downloaded and installed our versions on his computer... did not help... app still crashed.

Argh!!!!!!

Can you arrange to send me the app?

You can upload it to:

        http://www.ee-stuff.com
Of course it COULD be the much harder to find scenario where there is something running in the background on the machines on which the program crashes which interfere with the running of your program (most unusual).

Another thought, are all the machines running with the same screen resolution?
(a bit far fetched but we must look at everything).

Is it possible to do a screen capture of the Task Manager on a "rogue" machine as well as one on which the program runs (with the program running) and post them here?

Cheers
Chris

Another thought.

Is Firefox running on the PCs on which your application does NOT work?
There have been some issues of Firefox have troubles working alongside some apps (Particularly oine that make call to VB.Net 3.5)

Cheers
Chris

Of course one option could be that the machines having problems are ones on whch the registry is "mucked up" in some way.

Make sure you run some "maintenance" programs on those machines to clean up the registry (such as XTPro or thge myriad of other "maintenance" programs on the market).

Sorry about these "one by one" comments, but I am looking around to see if others have had a similar problem and am coming up with different ideas each time I go looking!  :-)

Cheers
Chris

Firefox is not running at the time... only Internet Explorer.

I have just uploaded the application installer 401k2011pro.exe

I have not tried cleaning up their registry.  

For the Task Manager screen shot... do you want a screen shot of the Processes?  or which screen?

I have not checked the screen resolution.  I can check that tomorrow.

As for apps running... we did try to kill just about every app that was running....  but that is hard to do the way computers run these days...many items in background.

I am considering also running DependencyWalker.com on their computer just to double check the components, controls and DLLs.

You would have been supplied a link for me to download from when you uploaded 401k2011.exe.

I need to know that link.

But after all this I MAY have the solution for you!

I am putting together a document  instructions on how to perhaps solve this issue vuia the Windows 7 Control Panel.

I will hold off downloading the executable until we conform that the procedure I am about to upload does not work....Please stand by.

Cheers
Chris

OK...there is no guarantee that this will fix your problem, but it is worth a try.

On a Windows 7 machine on which your application does NOT work, try the procedure in the document I have supplied below.

I found similar instructions on a Web search but they were poorly worded with very poor graphics, so I made up a new document after following the procedure on my own Windows 7 PC.

It will be interesting to see if it works.

Cheers
Chris


An-attempt-to-stop-applications-.mht

Just now reading this.... I do have the link do I just paste it in?  If so here it is:

https://filedb.experts-exchange.com/incoming/ee-stuff/8173-40.renamed-from-exe-for-your-safety

I looked at your mht doc and I do appreciate you taking the time to do that, but I have already done that ... I have added the app to the DEP exception list AND tried to run it in XP compatibility mode.... app still crashes.

Yes, that is what you do, just paste it (as you did).

I have downloaded the file and will investigate ASAP.

That is a shame about the DEP exception - I thought that might be the solution.
Oh well, continue with your "Dependency Walker" test while I ponder things further.

Cheers
Chris

EE bugs me when questions are inactive... I really dislike that.... but have not found what is causing this problem and it's a tough one...

I intalled you program on my Windows 7 machine and (thankfully) it came up with the "stopped working" message.

This means I can help you find the solution easier than if it worked!

I will dig and delve as well...

Please stand by.

Cheers
Chris

OK...I followed my steps exactly as showing in my document and then your application ran!

Please check carefully that you:

    1. clicked the check-box to make sure the application was "ticked" (step 8)

    2. clicked "apply" before clicking on the "OK" button (again step 8)

Since my procedure flow is exactly what you are experiencing, I cannot see why you are having this problem is you follow the steps exactly as shown in my document:
    "An attempt to stop application"  (link in comment 37253995 above).

I suggest you print it out (four pages) and follow it step by step through again to ensure you are doing exactly what I did.

When I first ran your application after installation it immediately came up with the "Application has Stopped Working" message.

No, after turning off "Data Execution Prevention" for your program, it immediately comes up with a box asking for my name and birth-date, then I am taken to a screen asking if I want to try it our, or buy it.

It looks quite good! (I might even buy it!)    :-)

Give it all a go again (after un-installing from any Windows 7 PCs that are giving you trouble but have it already installed.

It will be interested to see what happens.

Cheers
Chris
   

Any progress?

I cannot see why your program does not run if you follow the same steps I did.

I have proved that it works, from a situation where I received the error message on first run, performed the steps I outlined, then re-ran and it worked!

Please advise you have done the same thing (especially making sure the "check-mark" is in place before slicking on OK in step 8 of the instructions).

Cheers
Chris

Sorry for the delay but for some reason EE did not give me notice of your comments... or else they went into spam.... just checked this page manually....

I have previously added the app to the DEP exemption list and it still would not run... I will try it again though....  I will email this to the client and see if they can run through it...

Regards,
-Tim

OK...I will await your findings with glee (just returned from two weeks holiday in sunny Queensland and am only now getting back into the swing of things, after wading through 632 emails!)

Cheers
Chris

We tried the DEP instructions again and it did not help in this case.  Still same problem.

Two week holiday sounds lovely right now :-)

I would have to get back on customers computer to try it.... It will take a day or two to get that coordinated....

How's it going with your testing?

If it is solved could you please hold off awarding any points until after 1st February? (I have been unemployed for over 5 years now and it is a continual struggle for me to accumulate points to pay for my EE membership (I need 4000 each month).
I ave already acquired 4800 for January so any pending rewards would be best received in February for me.

I am confident the solution should be at hand since my Win7 PC reacted exactly like your customer's when the program first ran, but after applying the steps mentioned in my document attached under comment 37253995 (above) it worked perfectly! Care must just be taken that the steps are carried out EXACTLY as stated (it is easy to overlook checking check-boxes etc.)

Cheers
Chris

I do not have a solution to my problem but Craisin certainly tried his best.

Thanks do much for the points - I hope you eventually get it to work (as it did here).

At least the documentation may help others with a similar problem - it has certainly prepared me for future occurrences (it seems this problem rears it's head often when apps which ran on Windows XP are first tried out on Windows 7).

Cheers
Chris