i have written a Win32/net DLL, it works fine under Win XP, Win7 and 8 but under Win 8.1 it fails.
Dependency Walker says: API-MS-WIN-CORE-KERNEL32-PRIVATE-L1-1-1.DLL not found
(user32.dll will call them)
Google means, MS changed some System-DLLs in 8.1 (and ignored compatibility), so that many programs have the same problem.
Full list with "file not found":
API-MS-WIN-CORE-KERNEL32-PRIVATE-L1-1-1.DLL
API-MS-WIN-CORE-PRIVATEPROFILE-L1-1-1.DLL
MSVCR120.DLL
API-MS-WIN-CORE-SHUTDOWN-L1-1-1.DLL
API-MS-WIN-SERVICE-PRIVATE-L1-1-1.DLL
EXT-MS-WIN-NTUSER-UICONTEXT-EXT-L1-1-0.DLL
IESHIMS.DLL
Does someone have a idea how to fix this?
Dependency Walker's static analysis is not to be relied upon. The fact that Dependency Walker reports issues with those DLLs based on its static analysis does not mean that this is indeed your problem. It is normal for perfectly fine executables to report problems as you describe under static analysis, and yet execute perfectly well.
Right now I'm looking at Dependency Walker's assessment of my application and I see the exact same list of supposedly problematic files as you do. But the application runs perfectly well. Simply put, you are looking at a false positive.
Microsoft has certainly not ignored compatibility when upgrading operating systems. On the contrary, it goes to extraordinary lengths to maintain good compatibility.
If you want to use Dependency Walker to debug dependency problems with native DLLs, then you really need to use it in dynamic mode, using the Profile menu. This will tell you which dependency fails to load at runtime, if indeed that is your problem. But depending on exactly where the balance is between managed and unmanaged, it may be that Dependency Walker is not the right tool for the job.
And your problem may not be an issue with native dependencies. The first step is for you to diagnose exactly what the problem is. That's beyond the scope of this question because we don't have any details of the errors that you encounter.
Related
I have been trying to resolve .dll dependencies for the executable file with Dependency Walker. Currently, I am getting missing .dlls in the following form:
API-MS-WIN-XXX
EXT-MS-WIN-XXX
For example:
API-MS-WIN-APPMODEL-IDENTITY-L1-2-0.DLL
API-MS-WIN-APPMODEL-RUNTIME-INTERNAL-L1-1-0.DLL
API-MS-WIN-BASE-UTIL-L1-1-0.DLL
API-MS-WIN-CORE-APIQUERY-L1-1-0.DLL
EXT-MS-WIN-RTCORE-NTUSER-SYSCOLORS-L1-1-0.DLL
Does anybody have any ideas on how to resolve these?
Any help will be greatly appreciated!
Additional info: I compiled the executable using Visual Studio 2013. The most interesting thing is that I did not receive any errors during compilation. However, I cannot run it due to missing dependencies. I also attached a screenshot of dependency walker:
Update 1: As an attempt to solve the problem I tried to add the path for the libraries that VS used during compilation to the $PATH environment variable without any luck (Dependency Walker still shows unresolved dependencies).
These are API-sets - essentially, an extra level of call indirection introduced gradually since windows 7. Dependency walker development seemingly halted long before that, and it can't handle API sets properly.
So these are all false alarms and nothing to worry about. You're not missing anything.
Also see On API-MS-WIN-XXXXX.DLL, and Other Dependency Walker Glitches.
Edit: Only in Oct 2017 did someone finally try to fill this gap. Meet Dependencies by lucasg. I've only briefly fiddled with it until now, but it handles API sets well and is at least very worthy of attention.
In addition to what #Ofek Shilon said, I usually ignore following dlls that dependency_walker identified as missing when I try to find missing dlls for my program. You will see that your program runs fine when dependency_walker says these dlls are missing.
API-MS-WIN-*.dll
EXT-MS-WIN-*.dll
IESHIMS.dll
EMCLIENT.dll
DEVICELOCKHELPERS.dll
You can search for dlls other than the ones above to resolve your problem.
Dependencies program helped me find a missing DLL in no time. It is open source and available here: https://github.com/lucasg/Dependencies
I also ignore:
EFSCORE.DLL
WPAXHOLDER.DLL
I am building a win32 executable. The compiler is the latest version of MinGW. The library dependencies are GLUT and libpng.
I first tested on a windows 7 machine, and had to obtain libpng3.dll and freeglut32.dll. However, on XP, I had to (in addition) acquire zlib1.dll.
The XP machine was a VM with a fresh install, so I suspect a fresh win7 machine may also be lacking zlib1.
My question is how do I go about finding out which dll's I need to distribute? How do I know, a priori, which dynamic libraries are needed for my program to run on a particular system? I suppose this is what installer programs are for... I'm guessing that what the installer does is look through the system to find out which dependencies are unsatisfied, and then provides them. So this way if I were to distribute my program I could check if the user's machine already has zlib1.dll, and I won't install zlib1.dll if it's already found in the system directory. However I never found a document that said to me specifically, "libpng requires zlib", and so, until such point as I tested the executable on a machine lacking zlib, I was unaware of this dependency. How can I create my dependency list without having a fresh install of each version of every operating system to test on?
One idea I have is to decompile the executable, or through some method examine the linking process, to find all the libraries that are being linked at runtime. The problem now becomes figuring out which of these are supposed to already be there, and which of them I could be expected to provide in the distribution.
edit: Okay, I looked, and the installation of libpng I downloaded did provide zlib1.dll inside its bin directory. So not including it is pretty much my fault. In any case, Daniel's answer is definitive.
Dependendy Walker shows all deps of your program.
The correct answer to this question, in my view, is to start at the source rather than to reverse engineer the solution with Dependency Walker, awesome and useful tool though it undoubtedly is.
The problem with Dependency Walker is that it only tells you what one particular run of the program requires on the OS on which you run it. If you have any dynamic loading dependencies in your app then you would only pick those up if you made sure you profiled the app with Dep. Walker and forced it through those dynamic loads.
My preferred approach to this problem is to start with your own source code and analyse and understand what it depends upon. It's often easy enough to do so because you know it well.
You need to understand what are the deployment requirements for your compiler. You usually have options of linking statically and dynamically to the C++ runtime. Obviously a dynamic link results in a deployment requirement.
You will also likely link to 3rd party code. One example would be Windows components. These typically don't need deployment, you can take them as already being in place. Sometimes that's not true, e.g. GDI+ on Windows 2000.
Sometimes you will link statically to 3rd party code (again easy), but if you link dynamically then that implies a deployment requirement.
I have to maintain an old VB 6 ActiveX DLL called by another third-party program for which I have no sources. This DLL works and compiles fine against the API of said program for about 6 years and 3 major versions.
But now when I try to compile the DLL against a new major version the mentioned error occurs. It seems the error occurs before "my" code is called so there´s no use debugging or logging. The only remedy was to compile w/o binary compatibility which is no real option. My Google search turned up quite some people with the same problem but no solution.
Does anybody here know how to fix this issue ?
I finally figure out how to diagnose VB6 error 32801 in a systemic way.
My theory is When the VB6 compiler is creating a project or binary compatible library, the compiler decompiles the type information from the referenced library. Error 32801 occurs the source code's type information is not the same as the referenced library.
There is a tool called OLEView. This tool can decompile the COM type information into an IDL text. What I do is decompile the referenced library in to IDL and take the last good build of the failing library. Most times it is a build server version but the build does not work on a developer workstation. Decompile the last good build. Use a text comparison tool, like WINMerge, and find the differences between the type libraries. The differences make it easy to track down the problem.
Depending on the difference will determine how to correct. Mitigation can be done by either correcting the reference DLL, or by source code correction, or source code references.
It sounds like one of the types in the interfaces defined in your new DLL is different from one in the previous DLL. I'm deducing you use types defined in the third party program in your public interfaces of your DLL. It sounds to me like the third party has changed the definition of one of the types but kept the name and GUIDs the same. You could use something like OLE/COM Object viewer to check whether that's true. If it is true then you can complain to the publisher of the 3rd party program. Do you have enough political power to succeed?
Bruce McKinney, the guru who wrote Hardcore Visual Basic 6, ran into the same issue with a structure in a type library, where he changed some of the member types. The only fix he could find was (essentially) to break binary compatibility - and that's after some correspondence with the VB6 compiler team, who he knew fairly well. I don't think anyone else could do better.
There is a discussion about this error on devx.com that seems to indicate that the problem stemmed from Microsoft's Scripting Runtime (scrrun.dll).
FileSystemObject compatibility Unexpected error (32810)
Does your DLL reference that library? If so, can you remove the reference (e.g., replace FileSystemObject functionality with intrinsic VB file handling functions and/or API calls).
Are any of the files associated with the core project being compiled marked as Read-Only (i.e. not checked out of SourceSafe or similar repository)?
*.exp
*.vbw
*.lib
---------------------------
Microsoft Visual Basic
---------------------------
Unexpected error (32810)
---------------------------
OK Помощ
---------------------------
This the message I was getting trying to reference in VBIDE an old OCX that has been recompiled recently.
After somewhat long research the offending lines of code causing this error appeared to be
Property Get MouseActivate() As BookmarkEnum
Just changed this to
Property Get MouseActivate() As Boolean
. . . and the error was gone.
BookmarkEnum is an enum from ADO. Our build server is Server 2003 and my dev machine is Win10. The project references ADO 2.8 but apparently this typelib has some differences on Server 2003 vs Win10
I have a project which has several components loaded by a single preloader swf.
The preloader swf is strictly AS3 (No flex) and uses Loaders to load two different swfs which both use the flex library (Statically compiled, not rsl).
When I compile all three under linux and run the resulting preloader, one of the swfs fails to load properly, and the exception below (at the bottom of this post) is thrown.
If I compile the same component using the same ant task in windows, the component loads just fine without error. The windows file is also 683 bytes smaller.
This is true using the flex SDK 3.2.0 and 3.3.0 under linux and windows.
Have you seen this type of behavior? Can you offer any suggestions for why it might be happening, or how to determine what is wrong?
TypeError: Error #1009: Cannot access a property or method of a null object reference.
at mx.managers::FocusManager/activate()
at mx.managers::SystemManager/activateForm()
at mx.managers::SystemManager/activate()
at mx.core::Application/initManagers()
at mx.core::Application/initialize()
at OC_Footer/initialize()
at mx.managers::SystemManager/http://www.adobe.com/2006/flex/mx/internal::childAdded()
at mx.managers::SystemManager/initializeTopLevelWindow()
at mx.managers::SystemManager/http://www.adobe.com/2006/flex/mx/internal::docFrameHandler()
at mx.managers::SystemManager/docFrameListener()
So wait, are you using different version of the SDK in each platform? That would certainly account for some differences (at the very least in the size of the swf...)
IIUC you get this error when you're loading the page in the browser, right? It's hard to tell from just the stack trace what's wrong, but I can tell you that I used to get a similar error on Windows and it had to do with keyboard events (e.g. using the tab key to move between elements when popups are visible, and similar stuff). Sorry I can't offer a more accurate diagnosis.
I'm not sure I've solved the real problem (Why the compilation was different under different OS's), but I have found that the newer version of the flex SDK does not exhibit the same issues.
I created a bug for the issue here:
https://bugs.adobe.com/jira/browse/SDK-20147
The short of it is, build 3958 (The one default with flexbuilder at the time that I created the bug -- This may still be true) appears to have a number of minor bugs. Upgrading the flex SDK to build 4852 alleviates the symptoms, and I can build projects successfully in a number of environments.
Microsoft distributes source code to reference implementations of their different Direct3D APIs to hardware vendors, driver developers, etc. This code builds using the ever-cryptic WDK (formerly DDK) build system, and virtually never works out-of-the-box. Though widely used, this code is semi-private, so there is never any basic helpful information available on the wider web. This is commonly used enough (and a well-known pain in the ass in this community), and the basic build information insensitive enough, that it should be discoverable on Google.
The build readme suggests using the WDK and building with the command build -cz -daytona. This, confusingly, spits out a bunch of output yet builds nothing.
Getting past this, the Vista with WDK 6001.18002, the latest d3def9 source distribution fails in the link subproject with "failed to produce any output - warning treated as error."
The XP d3dref9.dll can also be confusing to build, frequently failing to find D3D headers and types.
There are generally two major issues quite common in building the refrast source drops as they come direct from Microsoft.
First, the build -cz -daytona command is either a typo or relies on undocumented additional external configuration. Building in this mode parses all the source, but never specifies which platform(s) to build. Since all platform dirs (daytona and win9x), where the actual outputs are specified, are "optional," nothing is ever actually built. The solution to this is to instead use the correctly-specified command build -cz daytona (no '-' on daytona). This should parse the sources and then actually build everything.
Past this, there are usually also problems with the out-of-the-box build setup.
The new WDKs (e.g. on Vista) generally fail in the final linking step with a spurious linker error. This is easily fixed by adding:
LIBRARIAN_FLAGS = $(LIBRARIAN_FLAGS) /IGNORE:4001
to the link/sources.inc build file. After this, build -cz daytona in the root of the source drop should build and link everything out-of-the-box.
On XP, it is also common to have issues if using older DDKs (pre-Windows Server 2003, i.e. "XP"-labeled DDKs). In particular, the refrast project relies on core D3D9 headers existing externally, and these are not included in the XP DDK. Simply using the latest WDKs (rebranded from "DDK" post-XP) solves this. Contrary to the naming, all newer WDKs are generally supersets of older releases, and so include build environments for platforms back through XP.
There may also be issues with some XP refrast source releases including code which triggers more pedantic compiler errors in the newer WDK compiler releases. These, however, can usually be easily fixed by iterative compilation and source tweaking in response to any simple safety/correctness errors raised by the compiler.