We have an application that sets up an IP address on a bit of embedded hardware. Part the the process is to setup and ARP mapping to map the new (but not yet assigned) address to the MAC address of the device.
Under XP this works perfectly and this code hasn't been touched since 2003. Under Win 7 64 bit (maybe 32 bit as well I haven't tried it) the call to CreateIpNetEntry returns a 0 success code but no entry is created in the ARP table. I'm running the exe as administrator so permissions shouldn't be the problem. I even tried adding a manifest file to force the requested execution level to requireAdministrator.
If it returned an error I might have something to go on but it returns a success code and doesn't do anything!
Related
*THIS HAS BEEN EDITED, SEE BOTTOM. I CHANGED THE TITLE TO BETTER REFLECT THE PROBLEM.**
I have an old vb6 application that I put on a windows 2016 server and been having issues with dependency files. I ran process monitor and started putting the dll files in the locations where it is looking at, most of them have cleared up.
I'm getting one that I cant find on the old win 2000 box or anywhere else: wow64log.dll
Where can I can get this file? I attached pics of proc mon and the list of dependencies that the app is requiring. any direction would be appreciated. third pic is the actual error when trying to open the app. edit added the dependency walker screen shot
EDIT***
so I have narrowed down the issue and it boils down to an ADO connection. I cant seem to connect on windows server 2016 using ADO. I suspect it has something to do with the connection string, but what baffles me is why does this work on a win 10,1803 box and not on windows server 2016 1607 ?
this is basically my issue - https://social.msdn.microsoft.com/Forums/SECURITY/en-US/f1eee40b-6ab2-445f-a361-ae965439273a/run-time-error-214746725980004005-for-using-adodbconnection?forum=isvvba
I suspect that this is not an actual error in the runtime of your program, If you are only looking at Procmon, be aware that it shows a lot of stuff and sometimes not all the "errors" there are really relevant. For instance, it will often show how Windows functions look in a long list of search paths, each failing in turn, before that actual location of a DLL is detected.
In this case, it seems most likely that a missing wow64log.dll is harmless and apparently, totally normal.
"WoW64" is the Windows subsystem which runs 32 bit programs inside the 64 bit operating system. ("WoW" stands for "Windows-on-Windows".)
According to the reference WoW64 Internals describing how this subsystem is initialized:
wow64!ProcessInit
...
It … tries to load the wow64log.dll from the constructed system
directory. Note that this DLL is never present in any released
Windows installation (it’s probably used internally by Microsoft for
debugging of the WoW64 subsystem). Therefore, load of this DLL will
normally fail. This isn’t problem, though, because no critical
functionality of the WoW64 subsystem depends on it.
Although that article is talking about the ARM64 architecture (which AFAIK is not what most PCs would be using) it sounds like much of the WoW64 system is similar to normal PCs.
I have a 32 bits executable that calls functions inside a Dll file. When installed, the dll is copied in the same folder of the executable and the system directory (system32 on 32 bit platform and sysWOW64 on 64 bits platforms). I've sucessfully tested this executable on:
a Pc with winXP 32 bits,
a Virtual Machine with Win7 32 bits,
two PCs with win7 64 bits,
a laptop with win8 64 bits.
Then a customer gave me a laptop with Win 7 64 bits. It is infected with a virus (those kind of virus that hide all your folders and files in your memory stick and create shorcuts). On this laptop, my executable is unable to find my dll despite it is copied in the respective folders. My exe shows an error message that says "Unable to find mydll.dll".
Is it possible that the virus is interrupting the calls to the dll and messing up with my executable?
Yes, a virus can hook into ("override") LoadLibrary or GetProcAddress and just return a null value.
Then you'll receive this message.
Or it can put itselfs into the dll-loading process (infection) and cause a failure by an unintended malfunction.
It can remove execution permission
Or it can override the dll's magic bytes, so the system does no longer recognize the dll as dll...
Or it can "override" the file listing API, and always return null...
Or it can also recursively load/call itselfs until a stackoverflow occurs (it can also do this with a time-delay, causing seemingly random crashes)
or... or... or...
Generally speaking, it's a bad idea to do any testing whatsoever on a machine you know to be infected with a virus. Certainly one that is obviously mucking with the entire system. You literally cannot trust any single thing being said by the system because it is compromised.
So, really this has nothing to do with whether or not your DLL can be seen, bla bla bla... You should be concentrating on wiping the drive on that machine and starting over.
And while you're at it, don't put that thumb drive into another machine. Put it on a Linux box and format it. (virus can't spread that way.)
Kind of a complicated question that I can't properly summarize in the title.
I have a 64 bit process (Foo64) that creates a 32 bit child process (Bar32), then tries to get the full path of Bar32's version of kernel32.dll. Obviously I expect Bar32 to have loaded it from C:\Windows\SysWow64\kernel32.dll
On Windows 7, I call GetModuleFileNameExA() from Foo64, and correctly get "C:\Windows\SysWow64\Kernel32.dll" back.
On Windows Server 2012, the exact same code gives me back "c:\Windows\system32\kernel32.dll", which is the 64bit dll location. It's obviously not possible for Bar32 to have loaded a 64 bit dll.
My hunch is that Server 2012 is telling me the location of where Bar32 tried to load it from, rather than the actual redirected location. How can I get it to tell me the true location?
Is there something fundamental I'm misunderstanding?
I have read all of the relevant MSDN pages, and the first three pages of all relevant google searches.
The 32-bit version of our app is unable to send email using MAPISendMail with 64-bit Outlook installed. It returns an error 0x80004005, about which I can find little information beyond the fact that it seems to be a MAPI initialization error.
According to this MSDN document, MAPISendMail is the one exception to the rule that 32-bit apps can't use 64-bit MAPI. And yet it doesn't work (at least with XP and Vista--we haven't tested Win7/8 yet).
Can anyone shed any light on this?
TIA
There are no exceptions: a 32 bit process cannot load a 64 bit dll.
When you have the 64 bit version of Outlook, the 64 bit version of mapi32.dll contains the actual implementation. The 32 bit version of mapi32.dll is a stub that does nothing but return an error.
That's not completely true #DmitryStreblechenko, - at least not for the MAPISendMail function. For that, and only for that, it is possible to build a "Outlook64 Bridge". This will then redirect 32bit MAPISendMail calls to 64bit Outlook. That bridge may look like:
[HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail\Outlook64Bridge]
#="Outlook64Bridge"
"DLLPathEx"="c:\\Windows\\winsxs\\x86_microsof t-windows-mapi_31bf3856ad364e35_6.1.7600.16385_none_ab239772 7b134496\\MAPI32.DLL"
"DLLPath"="c:\\Windows\\winsxs\\x86_microsoft-windows-mapi_31bf3856ad364e35_6.1.7600.16385_none_ab239772 7b134496\\MAPI32.DLL"
IMPORTANT, - you have first check to correct path of your 32bit mapi32.dll!
After adding these lines to the reg you have to set the Outlook64Bridge as your default mail client by:
[HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Mail]
#="Outlook64Bridge"
It is confirmed to work for simple 32bit applications which use really only the MAPISendMail function.
More information can be found here
Years ago I'had the same problem. I tried and tried again, but no way ... Microsoft blocked some interactions between 32 bit and 64 bit application: you can't even use 64 bit OCX/OLE in a 32 bit application.
The Outlook Bridge solution above (#VMAtm), worked in the beginning, then Microsoft fixed it, and it stoppend working.
In the end I realized a 64 bit application, my bridge application, to connect main 32 bit application with 64 bit outlook:
Main 32 bit application is running ...
Main 32 bit call bridge 64 bit application; mail data (from, to, title, body ...) are stored in a xml-file. The xml file is passed via command-line.
64 bridge applicatio starts, and call MAPI functions.
64 bit outlook does the rest.
This solutions works fine, and I'm quite sure I don't have to struggle with MAPI libraries.
I have set up the QODBC driver and was able to connect to my QB file and run queries in the VB Demo 32.
I am looking at one of the Sample Files, found here - http://support.flexquarters.com/esupport/index.php?/Default/Knowledgebase/Article/View/506/57/examples-of-how-to-use-qodbc-via-visual-basic
I did what this article said - copied all of the text into a text file, saved it as "Customer.vbs". I created a Customer named "Kim Garland", closed the dialogue box, double clicked on the file. The msgbox never displayed, and this error message came up - "[Microsoft][ODBC Driver Manager] The specified DSN contains an architecture mismatch between the Driver and Application; Code: 80004005; Source: Microsoft OLE DB Provider for ODBC Drivers"
Any idea what is going on here? After looking through the knowledge base, I thought it might have something to do with 64-bit vs 32-bit... but that didn't seem to get me anywhere. I do have Visual Studio installed, but don't quite know enough about VB6 apps to know what I'm doing.
EDIT
By the way, the line that is giving the error is:
oConnection.Open "DSN=Ben Test 2;OLE DB Services=-2"
I originally was using the same exact line that was in the article that I linked to, but that was not working either. I used the c:\windows\syswow64\odbcad32.exe to create a 32-bit DSN called "Ben Test 2". It didn't seem to change anything.
Please take a look at the Microsoft's website where they talk about it.
It is not VB issue, it is 32/64bit issue as you suspect.
http://social.msdn.microsoft.com/Forums/en/sqlgetstarted/thread/702f0d9b-6cb9-49cf-9953-80d059711e60
Since you are using 64-bit system, your VBS will be execute as 64-bit (by default).
QODBC is 32-bit driver, and can work with 32-bit applications. A 64-bit applications cannot talk to a 32 bit Driver and same is with 64bit application to 32 bit Driver.
For 64-bit applications use QRemote (which is a 64-bit Driver driver).
Solution 1
You can try to use QRemote to bridge QODBC and your application. Here is an article about how to use QRemote:
http://www.qodbc.com/qremoteconnect.htm
Solution 2
and there is another solution for you issue. Please call your VBS as 32 bit. Please follow the steps below:
1) Click Windows Start
2) Click Run, in the window, type "%windir%\SysWoW64\cmd.exe"
3) Click OK, then type "cscript vbscriptfile.vbs" in the cmd window
This will make your VBS run in 32-bit mode even thou you are in 64-bit machine
-Regards
Rajendra Dewani