I am trying to launch an external application from within my Win32 application but it's failing. Following is the code I am using:
HINSTANCE instance = ShellExecute(NULL, _T("open"), _T("loader.exe"), NULL, NULL, SW_SHOWNORMAL);
if((int)instance <= 32)
{
_cprintf("Error = 0x%X\n", GetLastError());
return 0;
}
The instance value I get is 0x00000002 and GetLastError returns 0x2. The same code works when I try to launch other applications like iTunes.exe or cmd.exe. Does it has anything to do with external application? By the way, win32 application and loader.exe application are located in the same folder.
Any help would be highly appreciated.
Farooq-
Well, error 0x2 is ERROR_FILE_NOT_FOUND
Looks like it can't find "loader.exe"
Error 2 is "File not found":
http://msdn.microsoft.com/en-us/library/ms681382(v=vs.85).aspx
I'm guessing it can't find loader.exe.
Put loader.exe somewhere in the search path, or provide the full path. That is how to avoid this file not found error. Windows error codes are all documented on MSDN.
Related
I am creating a child process which executes a batch file
success = CodebenderccAPI::CreateProcess(
NULL,
(LPWSTR)command.c_str(), // command line
NULL, // process security attributes
NULL, // primary thread security attributes
TRUE, // Inherit pipe handles from parent process
CREATE_NEW_CONSOLE, // creation flags
NULL, // use parent's environment
current_dir, // use the plugin's directory
&si, // __in, STARTUPINFO pointer
&pi); // __out, receives PROCESS_INFORMATION
The above code was tested and works as it should in various machines but recently failed in a Windows 7 machine and I am still trying to figure out why...
I have ensured that the user has administrative permissions to the folder where the batch file is installed as well as that the batch file is in the working directory. Moreover I disabled the antivirus (to verify that it didn't cause the problem) and tried again with no sucess. CreateProcess always fails with error code 2: ERROR_FILE_NOT_FOUND.
Any ideas what could cause that failure?
Finally I managed to find out what was causing CreateProcess failure.
Opened cmd and cd to the folder where batch file was located, then ran the batch file without any problem. After this, I navigated to the folder through file system and double clicked the batch file to run it. It failed with error message "Windows cannot find the_path_to the batch_file. Make sure you have typed the name correctly and try again."
According to this post the above error is related with the COMSPEC entry. Checked its value in registry and found that it was different from the default value. Updated its value to the default and problem was solved!
I have a funny problem on my machine
Windows 7 x64, using QT 5.2 for the GUI
I'm not able to start the app I always receive the error
First I thought I had a broken dll, so through some trial and error I found a solution:
I add the QT5Core.dll via enviroment path, and NOT directly to the app folder. Then the programm works. If I copy the dll back to the app Folder, Same problem as before!?!?!?1
I'm really confused, because the error only occurs on my machine?
Debugging doesn't really help,
In code, the error occures here:
MyApplication::MYApplication(int argc, char** argv, int version)
: QApplication(argc, argv, version) // <<< this call fails!
{ }
somebody can help me?
Why is the location of the qt5core.dll a problem?!?!?
UPDATE
I used the profiling function of depends and found the following behaviour:
Failing
GetProcAddress(0x76800000 [c:\windows\syswow64\KERNEL32.DLL], "CreateSymbolicLinkW") called from > "dirone\xxxx.EXE" at address 0x00FF2877 and returned 0x7688CCE9.
First chance exception 0xE06D7363 (Microsoft C++ Exception) occurred in "c:\windows\syswow64\KERNELBASE.DLL" at address 0x765CC41F.
Exception: "bad allocation"
Working
LoadLibraryW("C:\BuildPackages\QT\plugins\platforms\qwindows.dll") called from "dirtwo\QT5CORE.DLL" at address 0x66AA5154.
Loaded "c:\buildpackages\qt\plugins\platforms\QWINDOWS.DLL" at address
0x0F380000. Successfully hooked module.
somehow the path to the qwindows.dll is hardcoded into the dll (there is no environment path to this directory)
If I rename the qwindows.dll or delete it, startup failes again.
BUT the qwindows.dll is bundeld with our product. It is in a subdirectory ./platforms/
AND the files are the same (diff returns equal)
Somebody have some clue what I should try next?
Check if you already have some qt related environmental variables.
Crashes are usually due to this, remove those envronmental variables first. Check whether you have any other qt installed libraries.
it would be better if you can post the cal stacks.
Some other dlls are needed that reside in the directory of the qt5core.dll. When you add this path to the search path the dlls are found. When you simply copy the dll these dlls can not be found. You can check dependencies with the depends tool.
Candidates for the additional dlls are:
icuin51.dll and icuuc51.dll
Found the Problem:
The enviromentvariable:
QT_QPA_PLATFORM_PLUGIN_PATH=C:\BuildPackages\QT\plugins\platforms
was set to the path. If removing this variable, everything works as it should!
The win32 API SearchPath API fails to find the "telnet.exe" binary path even though its present in system32.
However when I did a search for notepad.exe, with the same code it returns the file path. What puzzles me here is that both notepad.exe and telnet.exe lies in the same directory i.e C:\windows\system32.
This is the code I have written
char path[MAX_PATH] = {0};
LPSTR* ptr = NULL;
DWORD dwRet = SearchPathA(NULL, "telnet.exe",
NULL, MAX_PATH, (LPSTR)path, ptr);
This would always return 0 and the GetLastError is 2 ( File not found)
Any idea what is happening here?
I am using windows 2008 R2 enterprise edition on an x64 machine
Thanks & Regards
Sunil
It's not working because you application is 32 bit and is being affected by the File System Redirector. Your application is not looking in C:\Windows\System32 but is instead being redirected to C:\Windows\SysWow64.
notepad.exe exists in both System32 and SysWow64, but telnet.exe only exists in System32. So you application does not find it when it searches the path.
You can disable this behavior for your application by calling Wow64DisasbleWow64FsRedirection. But note the warnings in the documentation links that indicate that this should only be disabled temporarily and then re-enabled.
I am running on a Win2K8R2 system that has Microsoft's NFS client installed in addition to the Windows CIFS client.
Given a UNC path (which the NFS client does support with caveats) I need to be able to tell if operations on the path would be handled by the CIFS or NFS client. WNetGetResourceInformation() would seem to provide this, but I have not been able to get it to work when the UNC path is to an NFS server.
Sample code:
int GetResourceInformation(TCHAR* path, void* buffer, DWORD* size)
{
TCHAR* p = NULL;
NETRESOURCE nr;
memset(&nr, 0, sizeof(nr));
nr.lpRemoteName = path;
DWORD dwRetVal = WNetGetResourceInformation(&nr, buffer, size, &p);
if(dwRetVal == NO_ERROR)
{
NETRESOURCE* tmp = (NETRESOURCE*)buffer;
wprintf(L"%s provider=%s system=%s\n", path, tmp->lpProvider, (p == NULL) ? L"<null>" : p);
}
else
{
wprintf(L"WNetGetResourceInformation failed for %s with error: %u\n", path, dwRetVal);
}
return dwRetVal;
}
I have also tried filling in the NETRESOURCE lpProvider and/or dwType fields as suggested in the doc but with no change in behavior.
If I pass the function a CIFS UNC path it succeeds. If I pass it an NFS UNC path it fails with error 487 "Attempt to access invalid address.". I also tried passing the native NFS path style hostname:/export/file but this fails with error 67 "The network name cannot be found."
I found the following sample for using WNetAddConnection2() with NFS but this code also fails for me with error 50 "The request is not supported". I can successfully mount the export using either "net use" command or the NFS-specific mount.exe tool provided by Microsoft.
Finally, WNetOpenEnum/WNetEnumResource does not return any NFS provider information for me or even show any connected drives that I have mapped via "net use" or mount.exe.
My general question is, has anyone had better success using the the WNet APIs with the NFS provider? Specifically, is there some mechanism I can use to determine the provider for a remote path?
Are you building as x86 or x64? It looks like the WNet* API's don't work correctly for NFS shares from an x86 process under WOW64. You can see this without writing code - if you have an NFS share mounted, "C:\windows\system32\net use" will show it, where "C:\windows\syswow64\net use" will not. Filesystem access seems OK the 32-bit process, but none of the APIs work.
Even built as x64, using a NULL lpProvider is inconsistent for me. Half the time it doesn't work, the other half it waits about 5 seconds before returning.
Calling WNetGetResourceInformation twice, once with a lpProvider of "NFS Network" and once with "Microsoft Windows Network" works consistently and returns instantly.
I am currently trying to debug my Crash-Handler, it is an external executable that gets called when my program finds an unhandled structured exception. I recompiled the crash-handler executable, and when I tested, I got a message: "Program too big to fit in memory".
After digging around for a bit, I found that this was being caused by the CreateProcess call within my unhandled exception filter. I found this post that says that this error message indicates that the executable is corrupted, however if I invoke the CrashHandler.exe from the command line, I get no such error.
Other Information:
I have tried rebuilding my
application and the crash-handler
multiple times in both debug and
release mode.
I have tried giving the running thread 2 orders of magnitude more stack space.
I tested the same CrashHandler.exe in another application that was already using it, and there were no problems.
I tried using a previous version of the exe that worked before, but with the same result.
Restarting the system.
My Call to CreateProcess:
//Fire off the Handler
//HandlerArgs = "CrashHandler.exe arg1 arg2 arg3 etc..."
if(CreateProcess(NULL, HandlerArgs, NULL, NULL, TRUE, CREATE_PRESERVE_CODE_AUTHZ_LEVEL | CREATE_SUSPENDED,
NULL, NULL, &StartupInfo, &NewProcessHandle))
Turns out that one of my post-build hooks was copying over the exe from The source control repository, and the file I had in the source control repository was actually the pdb. While testing I was copying directly to my running folder, and then the hook would copy the "corrupted" exe over again.