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.
Related
I'm working with a new property schema, and have been in the habit of checking the registry when I register or unregister a new version. One of the primary places to check this is HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\PROPERTYSYSTEM\PROPERTYSCHEMA.
Interestingly, I occasionally lose access to this registry location in Regedit. I see see this (note the absence of PropertySchema):
I know the schemas are still registered, because I can use the prop.exe tool and propschema SDK sample application to describe them. The properties are available in Windows Explorer and in Search.
Also, I can use PowerShell to list the contents of this hive:
C:\Users\carlton> cd hklm:
HKLM:\>
C:\Users\carlton> cd hklm:
HKLM:\> cd SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\PROPERTYSYSTEM\PROPERTYSCHEMA
HKLM:\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\PROPERTYSYSTEM\PROPERTYSCHEMA> dir
Hive: HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\PROPERTYSYSTEM\PROPERTYSCHEMA
Name Property
---- --------
0000 (default) : C:\Program Files\Internet Explorer\ie9props.propdesc
SchemaId : {D9B5ABA1-5E8A-4902-B6A1-50B3C0311C2E}
URI : ie9props.propdesc
CompactURI : 5376bae4b39f43768806afcb6b8ff5464bf9c989d1a819c6e6d99ba1e8ce2512
0001 (default) : C:\Program Files\Microsoft Office\Office14\Custom.propdesc
SchemaId : {537AAAB1-1D85-48DC-A99E-16EB8C309FE5}
URI : custom.propdesc
CompactURI : 2e3be58e5cbbc0da093956b46a3905f11cf0f5bbf11987a8619e25f7261ee8be
0002 (default) : C:\apps\MSOffice\Office14\VisioCustom.propdesc
SchemaId : {18503526-0466-4942-AC6E-41C1D380EABA}
URI : visiocustom.propdesc
...
Anyway, I don't understand how this happens, and whether I should be worried about it. Exporting this key from a colleague's machine and re-importing it can temporarily help, as it will show keys in Regedit that were hidden/missing (even if they weren't on my colleague's machine).
I'm in the Administrators group, running Windows 7 SP1.
The 32bit program data on 64bit systems available in 'Wow6432Node' folder of the registry (in above case 'SOFTWARE\Wow6432Node\MICROSOFT\WINDOWS...'). This is transparent to the applications, hence you can read data from applications but you don't see that in Regedit.
Harry Johnston's intuition was correct. I re-ran regedit from a command line with the path c:\windows\regedit, and I once again see what I expected under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\PropertySystem\PropertySchema. I could've sworn it wasn't showing it either, but it's working now, apparently.
I confirmed as much by exporting the parent key (PropertySystem) from the 64-bit and 32-bit regedit's and running Beyond Compare. The propdesc files are verily not there in the 32-bit version.
See 32-bit and 64-bit Application Data in the Registry (MSDN)
My VBA code can't access to my DLL in the C:\Windows\System32 folder on Windows 7 64bit and Word 2010 32bit.
Private Declare Function my_func Lib "mydll.dll" (ByVal param As String) As Long
Public Sub MyFuncTest
n = my_func("a")
End
I copied mydll.dll into C:\Windows\System32 and called MyFuncTest but got an error message like "Error 53: 'mydll.dll' not found".
However, I changed the declaration in code to:
Private Declare Function my_func Lib "C:\Users\myname\Documents\mydll.dll" (ByVal param As String) As Long
then I copied mydll.dll into C:\Users\myname\Documents, my account's Documents folder, and MyFuncTest successfully executed.
Changing "mydll.dll" to "C:\Windows\System32\mydll.dll" in the declaration did not work. And I tried accessing C:\Windows\System32\mydll.dll with FileSystemObject#FileExists method on the same VBA environment, but it returned False (not found).
There was no problem on Windows XP and Word 2003.
Can anyone help?
This is a 32 bit DLL and a 32 bit process running in the WOW64 emulator on 64 bit Windows. File redirection is in play and so when a 32 bit process looks in system32 it is actually redirected to the 32 bit system directory SysWOW64.
The simple and quick solution is to move the DLL to C:\Windows\SysWOW64. However, as Cody Gray points out in a comment, it is not recommended for you to place application DLLs in the system directory. Normal practice is to place the DLLs in your application folder in the program files directory and make sure that folder is in the DLL search path when the DLL needs to be loaded.
Seems like UAC is the problem. Try running the VBA script as Administrator. It may help you.
A recent developer suggested the following fix which allowed a 32bit .dll to be registered on a 64 bit machine
1) Open a DOS command window.
2) Navigate to C:\Windows\Microsoft.NET\Framework64\v2.0.50727
3) Enter the following and press enter.
regasm /codebase "C:\Users\myname\Documents\mydll.dll"
I have had exactly the same problem yesterday. The program run on my machine, but not on others.
In fact, the message fron Excel is wrong. He obviously find lhe dll file, but this dll is calling orher dll, missing in the system : MSVCR100D.dll and NTDLL.dll.
I found that by using Dependency Walker free software, able to examine which dll are call by a dll.
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!
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.
I have a 32-bit process that can run either in 32-bit or 64-bit Windows. So, naturally, if the process tried to access the file c:\windows\system32\file.ext, it would be redirected to c:\windows\SysWOW64\file.ext. So far so good - I don't want to disable the redirection.
My problem is that my process doesn't actually access the file - instead it just takes its path and writes it into a text file, and I want that text file to read SysWOW64 on a 64-bit system, and system32 on a 32-bit system. How can I do that?
The following code will return the correct system directory (system32\syswow64):
[DllImport("shell32.dll")]
public static extern bool SHGetSpecialFolderPath(
IntPtr hwndOwner, [Out]StringBuilder lpszPath, int nFolder, bool fCreate
);
public static string GetSystemDirectory()
{
StringBuilder path = new StringBuilder(260);
NativeMethods.SHGetSpecialFolderPath(IntPtr.Zero, path, 0x0029, false);
return path.ToString();
}
On x86 you'll get %windir%\System32
On X64 you'll get %windir%\SysWow64
Hope this is helpful
if I understood it correctly, you can use SHGetSpecialFolderPath passing CSIDL_SYSTEMX86 to the csidl parameter. The documentation for the valid csidl's states that a 32 bit process will get:
%windir%\system32 on a 32 bits OS
%windir%\syswow64 on a 64 bits OS
Best regards
System32 C:\Windows\System32 Windows System folder (system directory) for 64-bit files
SysWOW64 C:\Windows\SysWOW64 Windows System folder (system directory) for 32-bit files
Program Files C:\Program Files Folder for 64-bit program files
Program Files (x86) C:\Program Files (x86) Folder for 32-bit program files