Windows 7 app no longer will run

Hello,
I am at wits end on this one...

Windows 7 Home Premium... installed my SB7 installed app... works fine for awhile... then one day when you try to run it... you see the circle spin briefly and it doesn't open. But there is no error message.

It worked previously on the computer just fine. I have found 3 cases of this and another one from a customer today.

My only thought is that a Microsoft update has changed something on the computer but I don't know for sure. I personally have a laptop with the same 64-bit Windows 7 Home Premium and cannot reproduce the problem... the app runs fine.

I am at a loss as how to debug or fix this.

I have added the app to the DEP exclusion list and also turned off UAC just to make sure those were not the problem. That did not fix the issue.

Any ideas or help appreciated.

Regards,
-Tim

Hi Tim,

If your application depends on a specific VC++ (e.g. 2005/2010) runtime then it's well possible that one of the latest Windows update causes this. And of course, a new or updated anti-virus/anti-spyware product (or definition file) can cause this. If the three customers are running the same protection system then you have the culprit ;)

And what you can do is to provide the customers with a specific debug version of your program and let your program write "log" information into a log file (or add support for "DebugView") to see where it "hangs" and try to work-around it.

Hope this helps a bit.

Friedrich

We have tried disabling all anti-virus, anti-spam, and firewall programs.

That did not help. And also customers all had different programs.

I have been suspecting some automatic update of something from Microsoft because the programs did work and now they do not.

Am adding all updates from last 2 years to a laptop similarly configured... in groups of 10 trying to see if I can narrow down one of the updates as a culprit.

The program is a VB6 program and does not use C++.

Doing some logging would be good.... I would have to do that manually in VB6 or were you referring to some function of setupbuilder....

-T

Hi Tim,

You have to add some debug functionality to that program. SetupBuilder can only provide installation debugging and logging, but this issue is not related to the setup task at all. There is some kind of malfunction in the application -- I would suggest to use the "OutputDebugString" Windows API in combination with the "DebugView" program to monitor the system. This should help to find out where it "hangs".

Friedrich

I have found another case of this and compared where all the controls were installed. Is it normal that 32 bit controls get redirected into the SysWOW64 directory.

Hi Tim,

Yes, this is how x64 Windows works.

WOW64, short for "Windows-32-on-Windows-64," is responsible for providing two levels of support for 32-bit legacy applications. WOW64 prevents file and registry collisions between 32-bit and 64-bit versions of applications by redirecting the 32-bit registry and file system accesses.

SetupBuilder Developer Edition lets you create native 32-bit, hybrid 32/64-bit, or 64-bit enabled setup programs.

Although the WOW64 subsystem doesn't support every type of application, it does let Windows x64 run almost all 32-bit existing Windows applications. The types of applications that aren't supported are low-level applications such as antivirus programs or programs that attempt to directly access system hardware. The 32-bit applications that run in the WOW64 subsystem are executed at full speed. In fact, because of the larger data path the x64 architecture provides, many 32-bit applications will actually run faster in the WOW64 subsystem than they would on native 32-bit hardware.

The WOW64 subsystem isolates the execution of 32-bit applications from 64-bit applications.

First, the system files in Windows x64 Edition are not present on just the Windows\System32 folder, but split into two folders to separate the 32-bit applications from the 64-bit applications. The WOW64 subsystem intercepts calls from a 32-bit legacy application and redirects it to the Windows\SysWow64 folder. If the call is from a 64-bit application, then the call is routed to the Windows\System32 folder and does not involve the WOW64. Microsoft has retained the name System32 for the folder, which hosts the 64-bit system files. The "Program Files" folder on a x64 system which stores 32-bit legacy applications is named Program Files (x86). 64-bit applications are stored in the Program Files folder.

Second, the WOW64 subsystem also provides redirection at the Registry level. Computers that are running an Windows x64-based operating system use a different registry layout to handle both 32-bit and 64-bit programs. The registry layout changes in x64 Edition versions of the Windows operating system make sure that the programs hard-coded .dll paths, program settings, and other parameter values are not overwritten. If the call is from a 32-bit application, then the call to access the HKLM\Software registry hive is intercepted by the WOW64 subsystem and redirected to the HKLM\Software\Wow6432Node. If the call is from a 64-bit application, then it is routed to the HKLM\ Software node.

Registry Redirection

To prevent 32-bit registry settings from overwriting the 64-bit registry settings, computers that are running an x64-based version of Windows store the settings for 32-bit programs in a new branch in the registry.

32-bit programs and 64-bit programs that are running on an x64-based version of Windows operate in different modes and use the following sections in the registry:

· Native mode 64-bit programs run in Native mode and access keys and values that are stored in the following registry sub key:

HKEY_LOCAL_MACHINE\Software

· 32-bit programs run in WOW64 mode and access keys and values that are stored in the following registry sub key:

HKEY_LOCAL_MACHINE\Software\WOW6432node

This redirection lets you maintain separate configurations for 32-bit and 64-bit processes. 64-bit programs see the 64-bit version of the registry, while 32-bit programs see the 32-bit version.

File System Redirection

All 32-bit file access to the %systemroot%\system32 folder is redirected to the %systemroot%\syswow64 folder (the %systemroot%\syswow64 that contains a copy of 32-bit Windows system executable programs). This redirection lets a 32-bit applications load the correct 32-bit system executables rather than attempting to access the 64-bit OS executable programs.

Does this help?

Friedrich

I have had a generous customer let me remote into their computer, where this problem occurs, and test various debug versions on there....I decided just to log some debug info to a file.

Note again that the app works fine on some Windows 7 64-bit machines but on at least 3 customers have found it does not.

It is crashing when it tries to load the main form of the application. This would indicate to me that a control is in conflict or is not properly registered. I created batch file and called REgsvr32.exe on each control... then did Run as Admin on the batch file... all registered successfully....

App still crashes.... Baffled.... Given a VB6 project with "references" and "components"... what is the best way to determine what needs to be installed? My installer is also running the VB6 runtime installer from MS.

Hi Tim,

Unfortunately, there is no general answer to the question. It completely depends on what 3rd-party controls you are using and what you are doing in your program. There are a million possible reasons for your issue. You have to ask in a Visual Basic newsgroup (or Microsoft) what they recommend to fix this bug.

But what you can try is a "clean" standard Windows 7 installation in a virtual machine (e.g. VMWare). Then install your application to see if you can reproduce the issue.

And this might be a good starting point:

http://answers.microsoft.com/en-us/w...b-68b599b31bf5

Hope this helps a bit. Good luck :)

Friedrich

BTW, and here is another interesting "Support Statement for Visual Basic 6.0" reading:

http://msdn.microsoft.com/en-us/vstudio/ms788708

Friedrich