I'm working on a 64 bits application coded with .Net 4.0, C#.
In this application, at some point, I need to start another exe file using the following code :
l_process.StartInfo.FileName = _sFullFilePath;
l_process.StartInfo.Verb = "Open";
l_process.StartInfo.CreateNoWindow = true;
l_process.StartInfo.Arguments = l_sParams;
l_process.Start();
Now, this external application being compiled under 32 bits environment (x86), I get the following error :
**The specified executable is not valid for this OS platform**
Is it even possible to do so ? If yes, how can I manage to start this application from mine without having troubles ?
Usually, no extra work is required to run a 32-bit program on 64-bit machine.
Try to run 32-bit program individually.
Read this: http://www.techsupportalert.com/content/how-windows7-vista64-support-32bit-applications.htm
Related
There are a few questions (and unwanted answers) all over the forums about Microsoft.ACE.OLEDB.12.0 provider not being registered on the local machine, like this one. The gist of the problem, how I understand it, is that the application will look for the provider on the same platform as what the application is running on. So if your computer is 64 bit and the provider 32 bit, then there will be a mismatch if you don't compile the application to run in 32 bit mode.
Most answers effectively deal with this by installing the appropriate data components for the current platform. Other suggestions are to compile for whichever platform the data components are available.
I am developing an app using PCs running Windows 7, 8 and 10, all 64 bit, depending on where I am, but some have older versions of Office and others newer versions. This causes me to have to change the platform for which I compile depending on the PC I currently work on. While this is no problem for me, personally, I foresee this causing headaches for the end users not being able to run the program.
Trying to avoid asking users to install other components on their computers; is there a way I can tell the program to check the platform availability of the database provider and then run in that mode? Might it be possible to create 32 bit and 64 bit extensions of the database module and load the appropriate one regardless of the mode the main program is running in?
EDIT:
I just tried to compile my database extensions on different platforms Whichever one that is not the same platform as the application causes an exception when being loaded saying that I am attempting to load an assembly from a different platform. So I guess I'm out of luck with my option 2...
You can use CorFlags utility to modify your executable on target machine, after you will detect which mode it needs to run.
First ensure that your main exe is compiled under any cpu with Prefer 32 bit flag not set. Now when application is started you need to check if we are in 64-bit process or not, and also check your dependencies (this I won't cover - I don't work with OLEDB). If you found mismatch (say you are running in 64-bit process but your dependencies are 32-bit) - you need to run external process to modify your main executable and then restart it. Easiest way to do it is via simple cmd script, like this (in this example my main exe is called ConsoleApplication3.exe):
:start
start /wait "" "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\CorFlags.exe" ConsoleApplication3.exe /32BIT+
if errorlevel 1 (
goto start
)
start "" ConsoleApplication3.exe
Note that this is just example and if something goes wrong it will fall into endless loop, adjust to your requirements. What this script does is just updates your exe using CorFlags tool to run in 32-bit mode, then starts your main exe.
Right after starting your application, you might do the following check:
static void Main() {
if (Environment.Is64BitProcess) {
// here you also check if you have dependency mismatch, and then:
Console.WriteLine("Running in 64-bit mode. Press any key to fix");
Console.ReadKey();
// run script (here we assume script is in the same directory as main executable, and is called fix-mode.cmd
var process = new Process() {
StartInfo = new ProcessStartInfo("cmd.exe", "/c call fix-mode.cmd")
};
process.Start();
// here you should exit your application immediatly, so that CorFlags can update it (since it cannot do that while it is running)
}
else {
// after restart by our script - we will get here
Console.WriteLine("Running in 32bit mode");
}
}
Note that this tool (CorFlags) is available only with Visual Studio so you may want to pack it together with your application (might be not available on remote machine).
I am facing very strange issue:
I got a 64 bit c#.net application on 64 bit Windows Server 2008 R2 machine and it is being invoked by a Windows Service and it is started under Local System User, Moreover,this 64 bit c#.net application launches 32 bit java application and this java application has application data folder to C:\Windows\SysWOW64\config\systemprofile\AppData. 64 bit c#.net application has app data folder to C:\Windows\System32\config\systemprofile\AppData
So for 32 bit application app data folder is (in case of Local system User):-C:\Windows\SysWOW64\config\systemprofile\AppData
and for 64 bit application app data folder is(in case of Local system User):-C:\Windows\System32\config\systemprofile\AppData
Please Note: this is not typing mistake that they refer to opposite folders(it is a decision by microsoft for 64 bit OS), you can read https://msdn.microsoft.com/en-us/library/aa384187.aspx for detailed explanation.
Now, I need to write few files to 32 bit app data folder from 64 bit application as these files would be used by 32 bit java application.
So, I need to know How I can get 32 bit app data folder from 64 bit application using c#.net.
Important Note: this issue would be faced when application is launched under local system user (i.e. application has been launch by window services) and there won't be any issue when a user explicitly launches the application beacause in this case,user app data folder would be same for 64 bit and 32 bit application.
You first check if you actually are running inside of a 64 bit process on a 64 bit OS. And if so, you construct the path yourself. Otherwise you can just retrieve the system path and append your target path.
String path;
//detect if the current application is 64 bit and running on a 64 bit system
//NOTE: needs .NET Framework 4 to work
if (Environment.Is64BitOperatingSystem && Environment.Is64BitProcess)
{
path = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Windows), "SysWOW64");
}
else
{
path = Environment.GetFolderPath(Environment.SpecialFolder.System);
}
//append your target path
path = Path.Combine(path, #"config\systemprofile\AppData");
Please note that using EnvironmentIs64BitOperatingSystem and Environment.Is64BitProcess requires at least .NET-Framework 4.
The simplest solution is to rebuild the C# application as 32-bit, or to use 64-bit Java.
If you can't do either, create a 32-bit application that does nothing but look up the application data path, and run it from your C# application. The 32-bit application could be written in C, C#, or Java.
Are you using "shortcut" keyword to point appdata directory, eg %APPDATA%? Could you use a direct path, eg #"C:\Users\%username%\AppData\Local"
This is the same answer as #2 above (via Sebastian Baumhekel), with some errors corrected. I am on Win 7 and have the same issue. As some have pointed out this may not be future OS safe... However it solves my current issue.
The issue is on 64bit Win7 when you run a 32bit Windows Service as Local System user and ask for this folder:
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
It returns the 64bit version (with System32):
C:\Windows\System32\config\systemprofile\AppData\
Main point of clarification (as OP states):
SysWOW64 gets 32bit application data...
System32 gets 64bit application data...
This from OP link:
https://learn.microsoft.com/en-us/windows/desktop/WinProg64/file-system-redirector
I just wasted 4 hours of my life getting to the bottom of this so I wanted to clarify!
public 32bitWindowsServiceOn64bitWindows()
{
// Note: this service is configured to run as "Local System" user...
string appdata;
// need to do this, because this runs as Local System user...
// which gets the wrong SpecialFolder.ApplicationData (ie, System32 for 64bit apps) should be SysWOW64 (for 32bit apps)
if (Environment.Is64BitOperatingSystem && Environment.Is64BitProcess)
{
// the application is a 64 bit app
appdata = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Windows), "System32");
}
else
{
// the application is a 32 bit app
appdata = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Windows), "SysWOW64");
}
// Append your target path. Do you want Local or Roaming?
appdata = Path.Combine(appdata, #"config\systemprofile\AppData\Roaming\MyApp");
//appdata = Path.Combine(appdata, #"config\systemprofile\AppData\Local\MyApp");
...
I'm running a Windows 7 x64 machine when I do not compile for x64 I get an exception and my ListView just get populated with the first two non x64 processes.
That is I cannot access MainModule Property of a 64 bit process to get it's full path.
foreach(Process p in listaProcessi)
{
tempItem = new ListViewItem(p.Id.ToString());
tempItem.SubItems.Add(p.ProcessName);
tempItem.SubItems.Add(p.MainModule.FileName);
processiListView.Items.Add(tempItem);
}
I still can make it work compiling for x64 but suppose I want to compile just for x86, how do I avoid getting the excpetion ?
1) Is there any other way to discover those processes path ?
2) I could write a line like "You cannot get x64 Process path from x86 App", but still I don't have to run into the exception. How do I prevent this ? Can I check the process for a particular info so I can replace the text and avoid accessing MainModule ?
Thanks.
A 32 bit processes cannot access modules of a 64 bit process.
So it must be compiled for AnyCpu to be fully working in both x86 and x64 environments.
I'm using a 3rd party COM Library with C#, all works fine on 32 bit XP. I use tlbimp to create the wrapper, add a reference all works. However, when porting to our Server environment which is 64 bit Windows Server 2008, I've run into a road block.
The code below only runs properly when I right click and test it, ie run within the VS environment. The code does not work when compiled to a Console App, nor does the code work in an Assembly whether in test or called from a console App. In an attempt to get it working I'm running as Administrator and in a 32bit command window - still nothing grouper is always null, and no exception is thrown, indicating that GrpSvr.GrpCall is a valid Com Library name.
string sMessage = "no grouper";
GrpSvr.GrpCall grouper = Activator.CreateInstance(
Type.GetTypeFromProgID("GrpSvr.GrpCall")) as GrpSvr.GrpCall;
if (grouper != null)
sMessage = grouper.GroupInit(#"C:\CmdGrp.txt", true, true);
Console.WriteLine(sMessage);
Try using COM+ as host, and keep your application compiled for 64 bits. For more info see this link
It sounds like the 3rd party COM DLL is 32 bits only. You have to configure your app to run as 32 bits only, instead of any cpu.
I'm using:
FileInfo(
System.Environment.GetFolderPath(
System.Environment.SpecialFolder.ProgramFiles)
+ #"\MyInstalledApp"
In order to determine if a program is detected on a users machine (it's not ideal, but the program I'm looking for is a right old kludge of a MS-DOS application, and I couldn't think of another method).
On Windows XP and 32-bit versions of Windows Vista this works fine. However, on x64 Windows Vista the code returns the x64 Program Files folder, whereas the application is installed in Program Files x86. Is there a way to programatically return the path to Program Files x86 without hard wiring "C:\Program Files (x86)"?
The function below will return the x86 Program Files directory in all of these three Windows configurations:
32 bit Windows
32 bit program running on 64 bit Windows
64 bit program running on 64 bit windows
static string ProgramFilesx86()
{
if( 8 == IntPtr.Size
|| (!String.IsNullOrEmpty(Environment.GetEnvironmentVariable("PROCESSOR_ARCHITEW6432"))))
{
return Environment.GetEnvironmentVariable("ProgramFiles(x86)");
}
return Environment.GetEnvironmentVariable("ProgramFiles");
}
If you're using .NET 4, there is a special folder enumeration ProgramFilesX86:
Environment.GetFolderPath(Environment.SpecialFolder.ProgramFilesX86)
Environment.GetEnvironmentVariable("PROGRAMFILES(X86)") ?? Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles)
Note, however, that the ProgramFiles(x86) environment variable is only available if your application is running 64-bit.
If your application is running 32-bit, you can just use the ProgramFiles environment variable whose value will actually be "Program Files (x86)".
One way would be to look for the "ProgramFiles(x86)" environment variable:
String x86folder = Environment.GetEnvironmentVariable("ProgramFiles(x86)");
I am writing an application which can run on both x86 and x64 platform for Windows 7 and querying the below variable just pulls the right program files folder path on any platform.
Environment.GetEnvironmentVariable("PROGRAMFILES")
One-liner using the new method in .NET. Will always return x86 Program Files folder.
Environment.Is64BitOperatingSystem ? Environment.GetEnvironmentVariable("ProgramFiles(x86)") : Environment.GetEnvironmentVariable("ProgramFiles"))
C# Code:
Environment.GetFolderPath(Environment.SpecialFolder.ProgramFilesX86)
Output:
C:\Program Files (x86)
Note:
We need to tell the compiler to not prefer a particular build platform.
Go to Visual Studio > Project Properties > Build > Uncheck "Prefer 32 bit"
Reason:
By default for most .NET Projects is "Any CPU 32-bit preferred"
When you uncheck 32 bit assembly will:
JIT to 32-bit code on 32 bit process
JIT to 32-bit code on 64 bit process