Apparently when I run some 32-bit apps I created using gtkD on Win64 systems with Symantec Endpoint Protection installed and network drives mapped, and try to bring up a file dialog, something in the runtime attempts to load SnacNp64.dll, a 64-bit DLL, into 32-bit address space. This DLL is a component of Symantec Endpoint Protection that's used for networking stuff, hence this error only happening under such a narrow set of circumstances.
When I run a program from a Win64 native console and try to load a file dialog, I get:
The image file C:\Program Files
(x86)\Symantec\Symantec Endpoint
Protection\SnacNp64.dll is valid, but
is for a machine type other than the
current machine. Select OK to
continue, or CANCEL to fail the DLL
load.
When I select cancel everything works fine, and the program seems to suffer no ill effects from the DLL failing to load. When I select ok, I get an access violation, presumably because gtkD tries to load a 64-bit DLL into a 32-bit program.
However, when I run from a Cygwin terminal instead of a native Win64 one, it seems that the Cygwin console catches the error and forces the DLL to be loaded, thus crashing my application.
This error does not seem to happen for other 32-bit GTK-based apps, such as GIMP, on the same machines.
Basically, how do I make absolutely sure that my 32-bit app never tries to load a 64-bit DLL under any circumstances?
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.
Apologies for any foolish mistakes I've made in my code - I'm new to DCOM and VC++ as a whole. I know the basics but unfortunately not enough to figure this out.
Currently, I have some VC++ code that calls the equivalent of this in Powershell
$excel = [activator]::CreateInstance([type]::GetTypeFromProgID("Excel.Application", "127.0.0.1")); $excel.RegisterXLL("Path\to\x64\dll.dll"). Now if i use this PS Snippet on both x86 Powershell and x64 Powershell targeting an x64 COM server, it, well, suprinsingly works.
I then tried replicating it in C++, and got this far. For clarification, SimpleDLL is a extremely simple DLL that calls WinExec() in DLLmain and pops a calculator App.
https://gist.githubusercontent.com/realoriginal/4178718ee114e3e23c5ebe4651763044/raw/425ce397ed4788c9fac25ae39dcfe1db779c8d99/source.c
This code works fine if the server is x64 and its compiled as an x64 binary. Additionally, it also works if the server is x86 and the binary is compiled to x86.
The problems start arising if I target an x64 server with an x86 binary. I tried using CLSCTX_ACTIVATE_32_BIT_SERVER but that doesnt work at all, as the method is only available in x64.
On the other hand, if I keep it as it is, it sometimes works. To explain what I mean by sometimes, here are my results that I get from it x86 client targeting an x64 Windows server calling this method.
The client triggers an ACCESS VIOLATION with 0x000001 (no idea why)
The client errors at CoCreateInstanceEx() with 0x8007000E: Not enough storage is available to complete this operation.
It loads the x64 DLL and pops the calculator on the remote server
My question is, what could be causing it to fail in those instances that it did, and how could I make it work 100% of the time with x86 client towards x64 COM+ Windows Server?
I have a mixed managed and unmanaged C++ application that's working quite well. I'm using Visual Studio 2013 to compile it, and all is well. Recently I upgraded my computer to Windows 10, and now it's not working.
If I get the executable compiled on Windows 8, it runs properly on Windows 10. It only fails if I compile it on Windows 10.
The failure is peculiar as well. I run the EXE and nothing happens. When I run it from Visual Studio it doesn't even reach the first line of main. Breakpoints are all marked as 'disabled'. When I break the running process the debugger shows an empty stack trace.
UPDATE: Hunch about DLL loading turned into a fact:
I used Process Explorer and I see the process has two threads. The one starting at !CorExeMain is stuck at !LdrLoadDll, but I can't tell which DLL that is.
OK, found the DLL that causes the problem. I've created a C++/CLI console application, used that DLL and got the same behavior. The DLL is part of the application (and part of the VS solution). It's a native C++ DLL, compiled with the same compiler and settings. This DLL references other DLLs unfortunately.
This is a generic problem called "LoaderLock". The operating system makes very strong guarantees when it calls the DllMain() entrypoint of a DLL. Strictly in loading order, they never run at the same time. There is a lock in the OS loader that ensures these promises are kept.
And a lock always has the potential to cause deadlock. It will happen when the DllMain() entrypoint does something unwise like loading the DLL itself with LoadLibrary(). Or call a function that requires the OS to have a DLL already loaded. Can't work, its DllMain() entrypoint can't be called because the loader lock is held. The program will freeze. C++/CLI apps are prone to this problem, lots of stuff tends to happen in DllMain(). Indirectly, you can't see it in your code.
You can only see it with the debugger. You must change its flavor, Project > Properties > Debugging > Debugger Type, change it from "Auto" to "Mixed". You'll now also see the unmanaged code that is running including the OS loader functions, name starts with "Ldr". Be sure to enable the Microsoft Symbol Server with Tools > Options > Debugging > Symbols. And be sure to use the Debug > Windows > Threads debugging window as well, the truly tricky loader deadlocks that don't repeat well or appear to be affected by the OS version are caused by another thread loading a DLL.
Diagnosing and fixing it can be difficult, be sure to reserve the time you need to dig in. If you can't make heads or tails of the stack traces then post them in your question.
Before taking #Hans Passant advice I carefully combed through the code, dumpbin /dependentsed the executables and DLLs and made sure there were no custom DllMains. There were none. DLLs were indeed loaded with LoadLibrary, but that was happening long after the loading DLLs were loaded.
So I took #Hans Passant advice. Set up the debugger properly and checked the state of the process during the deadlock. One of the threads was stuck in LdrLoadDll.
It took a little tinkering to find the name of the DLL that was passed to LdrLoadDll. It was AVGHOOK.DLL .
I disabled AVG, and lo and behold - everything is back to normal.
This is the second time AVG is messing with me. The previous time I nearly replaced a printer until I figured out all the PCL errors disappeared when I disabled AVG. I think I'm not going to use it any more.
I have put our comment ping pong into a full text:
#1:
As you found out, that your application did not load, you needed to check if applications on your system (W10, VS2013) run at all.
Reply: A test console app is running fine.
#2:
If your application doesn't run, build up a similar application and step-by-step put code of your app into the new app until it fails.
If the failure is causes by a DLL (which cannot be loaded, as it was in your case), remove DLLs from your app until it works. Alternatively build a dummy console app, include DLL #1 and use some functions of that DLL. Compile, run, check. Go on until DLL #n...
Reply: faulty DLL was found.
#3:
Reference only this DLL in the test app to ensure it's this DLL only and not a combination of DLLs.
Is it a managed DLL or a native C++ DLL?
If the faulty DLL is from a foreign source: bad luck. Ask the developer for support.
If it's your own: Did you compile the faulty DLL on W10+VS2013, too, or did you copy it from your previous system? I suggest you compile this DLL again on the new system.
Reply: it's a native C++ DLL, which is part of the solution and is compiled together with the main app.
This DLL references other DLLs unfortunately.
#4:
Create a new console app, that references not your faulty application DLL, but the DLLs which are referenced by YOUR DLL. Omit the intermediate step to detect if the failure comes from the other DLLs.
The general procedure is: Split up faulty code to find out out which part is causing trouble. Romans already knew this 2000 years ago: Divide et impera ;-) Though they did it in a different context...
We had the exact same problem here during several weeks ! And we finally found a solution !
In our case, it was the anti-virus Avast which was corrupting the generated .exe !
The solution was to simply disable all agents while generating the release !
If you use another anti-virus, try to disable it.
I have an executable compiled by MSVS2013 on Windows 7 SP1 32 bit with C runtime statically linked and platform toolset "Visual Studio 2013 - Windows XP (v120_xp)"
It runs perfectly on Win7 (see attached screenshot of Dependency Walker profiling).
It fails to run on WinXP:
Here is the profile log:
Starting profile on 12/9/2014 at 2:55:03 AM
Operating System: Microsoft Windows XP Professional (32-bit), version 5.01.2600 Service Pack 3
Program Executable: c:\temp\OCTOPUS.EXE
Program Arguments:
Starting Directory: C:\Temp\
Search Path: C:\Program Files\ActiveState Komodo Edit 8\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\MATLAB\R2009b\runtime\win32;C:\Program Files\MATLAB\R2009b\bin;C:\VisaPoint\sbperl\perl\bin
Options Selected:
Simulate ShellExecute by inserting any App Paths directories into the PATH environment variable.
Log DllMain calls for process attach and process detach messages.
Log DllMain calls for all other messages, including thread attach and thread detach.
Hook the process to gather more detailed dependency information.
Log LoadLibrary function calls.
Log GetProcAddress function calls.
Log thread information.
Use simple thread numbers instead of actual thread IDs.
Log first chance exceptions.
Log debug output messages.
Use full paths when logging file names.
Log a time stamp with each line of log.
Automatically open and profile child processes.
--------------------------------------------------------------------------------
00:00:00.000: Failure starting the process. %1 is not a valid Win32 application (193).
[1]: http://i.stack.imgur.com/m82n6.png
[2]: http://i.stack.imgur.com/6Yr37.png
Modern versions of Visual Studio, starting with VS2012, use linker settings that marks the executable image compatible with the current generation of Windows. Version 6, started with Vista. XP and Server2003 were in the previous generation, version 5.
You can still build programs that run on XP with VS2013. But you have to make a setting change. Right-click the project, Properties, General. Change the Platform Toolset setting to v120_xp.
There are a few consequences, your program gets built with an old version of the Windows SDK. V7.1, the last one that was still compatible with XP. The C runtime library makes a bunch of operating system calls that are only available in generation 6. It will stumble along without them, affecting relatively minor details related to threading and culture. This is the kind of FUD that ought to remind you that it might not be the best idea to still promise support for such an ancient operating system. Make sure you keep a running version of XP around so you can properly test and repro. And keep in mind that you can't install VS on it anymore so if you do get a support call from an XP user then you tend to get a fairly heavy migraine.
Ok, just forgot to set SUBSYSTEM in Linker options.
Here is a link with explanations:
https://software.intel.com/en-us/articles/linking-applications-using-visual-studio-2012-to-run-on-windows-xp
My program dynamically loads a number of DLL's using LoadLibrary and (on literally all machines) these load successfully, on one machine some of these DLL's do not get loaded. I added code to trace lasterror and this reports "0x43 The network name cannot be found.".
The machine in question is running Windows 7 Enterprise x64, the DLL is a 32 bit DLL, this shouldn't be an issue and (in fact) this is my development environment.
I also tried converting the name of the DLL (which includes the path) to a short filename and used that in the call to LoadLibrary, I still got the same error.
Any ideas?
//*eggbox
Download Procmon let it run and filter for you dll name. This will immediately give you the locations where the dll was searched and which access path did return 0x43.
You get even the call stacks if you have the pdbs for your code as well (C/C++ only no managed code).
Run the program through Dependency Walker in its Profile mode and let that fine tool tell you exactly what is going wrong.