Printable View
Hello,
on a customers pc I have the following problem:
I want to run an exe file with CreateProcess, but this generates the error 193 which means
ERROR_BAD_EXE_FORMAT
%1 is not a valid Win32 application.
This is strange because there are no known problems with this file before for many years on many different windows versions.
The customers uses win7/32.
I use it with win xp and win7/64.
The file was compiled with vc 6.0.
What can cause this problem?
Help.
Thx.
Ralf
File corruption?Quote:
Originally Posted by Ralf Schneider
Can you run it from the command line or from windows explorer?
Hello Vladimir,
it is difficult to test it on the users pc.
But is that possible?
It is written to the drive from the setup medium (CDROM), directly.
The setup was done more than once to check setup problems.
If there is a problem, there has to be an setup error.
First, are you giving the full path of where this process exists? If not, then you're gambling that there are no other processes on the customer's system that doesn't have the same name as the one you think you're running.Quote:
Originally Posted by Ralf Schneider
If for some reason, the customer has a 64-bit app on their 32-bit system with the same name as your process, then that is an error if Windows happens to find that app first and attempts to run it.
You should guarantee, either by hard-coding or environment/INI/registry setting, or by some other means, that the path is a well-known, unambiguous path to the process you want to run. Otherwise, you risk running not only "bad" processes, but maybe another totally valid but different process that happens to be named the same as the one you think you're running.
Regards,
Paul McKenzie
Hello Paul,
thx.
But that can not be the reason.
I use the full path in the CreateProcess-call.
You don't know the reason, so why are you so quick in eliminating the reason I gave? If a process cannot be created, the obvious reason that someone would investigate is ifQuote:
Originally Posted by Ralf Schneider
1) The process name is incorrect (the drive, name, extension, etc. have bad, stray, or whitespace characters) or
2) The process exists, but is not the one you're trying to run (i.e. running 64-bit process with the same name, but on a 32-bit OS) or
3) The process is actually corrupted.
Do you log or trace the actual name of the process you're sending to CreateProcess? Do you create this process name programatically? If so, then maybe your program has a bug and is not creating the process name correctly. Again, unless you log carefully what you're sending to CreateProcess, you are not sure what the name might be. That's why you always log to a file, or the debug monitor, or somewhere, so that when you do get a customer issue, you have a log of things that are being done.
To check if a process is corrupted, have the customer go to the command-line and run the process in question by typing in the name of the process you're trying to run. If you can't run the process from the command-line, then the process is corrupted and you need to investigate from there.
Regards,
Paul McKenzie
Hello Paul,
thx.
Problem solved.
I think it is a problem especially with the German windows version.
In the folder "C:" the user has a file called "Program" and the folder "Program files".
Both will be translated into the German word "Programme". So CreateProcress was confused and could not find the correct folder!
Ralf
Did you hard-code the name of the Windows system folders? If you did, then that is the cause -- you should never assume what the names of the system folders are.Quote:
Originally Posted by Ralf Schneider
There are API functions that return to you the names of the system folders. You should be using those to return to you the actual names of the folders.
Regards,
Paul McKenzie
It is your and only your serious mistake to hard code the path for "Program File" folder.Quote:
Originally Posted by Ralf Schneider
Note that it may be either "Program File" or any other name. It may had been created either on drive C:\ or on any other available drive.
Rather then hard code this name you should obtain the actual name for "Program File" using SHGetFolderPath API (passing CSIDL_PROGRAM_FILES as a nFolder parameter)
@all.
I did not hard coded it!
And I provided CreateProcess with the correct path, but Windows was confused with two files/folders which were translated to the same name. In the users system you could see in windows explorer a folder and a file with the same name called "Programme".
Ralf
Sorry, Ralf, Windows is never confused, except case you've provided a hard-coded path "Programme" instead of "Program Files" (or vice versa).Quote:
Originally Posted by Ralf Schneider
Calm down and read again the answer that Victor kindly gave you.
...besides, the "Program Files" special folders may be different not only in different Windows languages distributions, but also in different Windows versions. So, again, as Victor kindly suggested, for special folders use the path retrieved by SHGetFolderPath instead of hard-coded paths.
Hello,
I am happy to have a forum to get help, but once again:
the path was not hard coded.
I get the path from CWinApp::m_pszHelpFilePath.
Then I extract the path from the string and add "app.exe".
Then I use it in CreateProcess.
After the user deleted the second "Programme", it worked.
You can believe me, in the users windows explorer there where two times the folder/file "Programme" right after each other.
Ralf
So now you mention MFC (from VC 6.0, circa 1998). From your original post, you did not mention anything about MFC, only that you attempted to figure out why Program Files is "Programme". If you would have clearly stated how you obtained your file name, then someone would have directed you or cleared up what the issue is.Quote:
Originally Posted by Ralf Schneider
Regards,
Paul McKenzie
m_pszHelpFilePath is a public member of CWinApp, so it can be changed anytime in a program. For that reason using it to extract the application path isn't reliable.
Much better is to use ::GetModuleFileName. Here is an example:
You can further use it to compose full-path-and-file name of other files in aplication's folder or subfolders, withouth fear that system is getting conffused. ;)Code:CString CMyApp::GetAppPath()
{
CString strPath;
::GetModuleFileName(NULL, strPath.GetBuffer(_MAX_PATH), _MAX_PATH);
strPath.ReleaseBuffer();
strPath = strPath.Left(strPath.ReverseFind(_T('\\')));
return strPath;
}
Example:
Code:CMyApp* pApp = (CMyApp*)AfxGetApp();
CString strAppPath = pApp->GetAppPath();
CString strFullPathAndFileName = strAppPath + _T("\\testapp.exe");
STARTUPINFO startupInfo = {0};
PROCESS_INFORMATION processInfo = {0};
BOOL bRet = ::CreateProcess(strFullPathAndFileName.GetBuffer(0),
NULL, NULL, NULL, FALSE, 0, NULL, NULL,
&startupInfo, &processInfo);
strFullPathAndFileName.ReleaseBuffer();
See also this FAQ: How to get the application directory?
Just few words about "Program Files" special folder:
It can have different names on different language Windows systems (e.g. AFAIK, German name of this folder is "Programme").
So a reliable method to get it is (as already pointed in this topic) with the help of SHGetFolderPath Windows API function.
However, on Vista or newer 64 bit systems, there are two special folders of this kind: "Program Files" and "Program Files (x86)" (fore sure, there is something similar in German systems). See FOLDERID_ProgramFiles, FOLDERID_ProgramFilesX86 and Remarks in this MSDN article: http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx.
For that systems prefer using SHGetKnownFolderPath instead of SHGetFolderPath.
[ Later edit ]
One additional note:
All above special folder names are just default. Probably, someone with strong muscles, can change them anytime by a call of SHSetFolderPath or SHSetKnownFolderPath (e.g "HumptyDumpty" and "HumptyDumpty (x86)". :D