views:

207

answers:

3

We have a WinForms app that runs fine on x86, but has many third-party components that make win32 calls. To get the apps to run on x64, I now compile for the x86 platform. Our habit has been to install our thick-client outside the system partition on servers, so we installed in "F:\Program Files (x86)" yesterday on a Win2003 x64 server. When run from that directory, the processes refused to exit. I tried killing them in Task Manager, taskkill, and Process Explorer, but nothing short of rebooting the server would kill those processes. When I uninstalled and reinstalled in C:\Program Files (x86), the processes exit fine.

Does the installation location really matter when running WinForms apps compiled for x86 on an x64 machine?

+1  A: 

From my experience I can tell that it is possible to run x86 binaries on x64 systems from pretty much any location (haven't tested if things still work if the binary is in system32, but I'm sure x86 programs can run from Program Files). I believe the Program Files / Program Files (x86) folders are just there to easily distinguish between native x64 apps and old x86 apps. From your description what you're facing sounds much like a WoW64 compatibility issue, however if you've got dependencies on unmanaged code you'll probably want to verify first if that unmanaged code runs fine and then dig deeper in what's preventing your program from closing. Also, it would be helpful to know how are you trying to terminate the application in the first place, if it uses multiple threads or a single thread, the version of the .NET runtime that's targeting and the version that's installed on the server (incl. Service Pack).

emaster70
It is a WinForms app, so I tried terminating the application using the "X" button in the upper-right corner of the screen.The app does some multi-threading operations, but all using the BackgroundWorkerThread component.The app targets .NET 3.5 SP 1. The server has .NET 3.5 SP 1.In all honesty, I could not return to the app to test whether this is a repeatable behavior because I did not want to have to reboot the server.
flipdoubt
+1  A: 

Here's a shot in the dark. Does your program attempt to read or load any data that is deployed with the application in the same directory or a sub directory? If so, there's the possibility that you are running into the following problem.

It's possible that your application is using a value that is dependent on the processor architecture that it is running under to find the directory. Take for instance the environment variable ProgramFiles. On a 64 bit machine, the ProgramFiles environment variable will actually point to the "Program Files (x86)" directory for a 32 bit application. So it's possible you're program is attempting to load data like the following and crashing

string root = Environment.GetVariable("ProgramFiles");
string file = Path.Combine(root, "MyAppName\DataDirectory\SomeDataFile.txt");
string data = File.ReadAllLines(file);

The last line would fail because the path would resolve to

c:\program files (x86)\MyApplication\DataDirectory\SomeDataFile.txt

But the application was deployed into Program Files. So the real path would be

c:\program files\MyApplication\DataDirectory\SomeDataFile.txt

JaredPar
Thanks, but the app uses Application.StartupPath whenever searching for files in the application directory.
flipdoubt
@flipdoubt, oh well, worth a shot
JaredPar
A: 

Have you tried attaching a debugger? If so, can you share what you've found?

David Pope