Troubleshooting DLLs

From K-3D

Overview

The overwhelming majority of K-3D support issues on Win32 involve Dynamic Link Libraries, or DLLs for short. Either required DLLs are missing, or they're installed but are the wrong versions, or they aren't installed where K-3D can find them, or some combination of the three. The problem is often exacerbated by inconsistencies between different versions of Windows. This set of issues is often referred to as "DLL Hell" and is not specific to K-3D. Unfortunately, there usually isn't an easy solution to troubleshooting DLL Hell, you have to roll-up your sleeves and learn a few things about how Windows works. The following steps will get you started:

Use Dependency Walker

Your best friend for troubleshooting DLL issues is the Dependency Walker tool, which can be downloaded for free from http://www.dependencywalker.com/ - it allows you to analyze a program (K-3D in this case), and see which DLLs are required for it to operate, and whether they can all be found:

Static Analysis

Dependency walker can perform a static analysis, allowing you to see in advance which DLLs will be loaded by a program at startup, and identify any DLLs that are missing:

• Run Dependency Walker (depends.exe).
• Use the File > Open menu to select the K-3D executable (k3d.exe).
• Ensure that the View > Full Paths menu item is enabled, so you can see complete paths to each required DLL.
• Check the upper-left and lower panes in the Dependency Walker window to see which DLLs are required to load K-3D successfully.
• Note DLLs that are highlighted with a question mark icon and/or red warning messages. These are DLLs that cannot be located, which will prevent K-3D from running. Either your PATH environment variable does not include the directories where these DLLs are installed, or the DLLs are missing.
• A more subtle problem is when there are multiple copies of a given DLL installed on your system, and wrong one is loaded at program startup. In this case, it's necessary to carefully examine the file path of each DLL in the Dependency Walker panes to see that the correct DLL will be loaded.

Dynamic Analysis

Some problems cannot be identified using static analysis alone. If you find that everything in looks fine in Dependency Walker, but K-3D still fails at startup, it's time to do dynamic analysis. In this case, Dependency Walker will monitor a running program, and provide detailed information about each attempt to load a DLL:

• Run Dependency Walker (depends.exe).
• Use the File > Open menu to select the K-3D executable (k3d.exe).
• Ensure that the View > Full Paths menu item is enabled, so you can see complete paths to each required DLL.
• Use the Profile > Start Profiling menu item to start K-3D.
• In the "Profile Module" dialog that opens, choose "OK".
• Watch the startup messages in the lower Dependency Walker pane for errors.

Communicating Results

You can use File > Save to save the results of your current Dependency Walker session and share it with others - this is the easiest and least error-prone mechanism for communicating the results of a Dependency Walker run. Note that the *.dwi files are too large to send to the mailing list, you will have to link to a file stored on a publicly-accessible server of your own.

Specific Problems

Following are some common problems with suggested solutions.

"This application has failed to start because python24.dll was not found. Re-installing the application may fix this problem."

This error indicates that the Python 2.4 library either doesn't exist or can't be found. The error is harmless unless you want to use K-3D's Python script engine. Try running the K-3D all-in-one installer, which includes Python 2.4, or install (or reinstall) Python 2.4 manually. We have anecdotal evidence that using the Python installer without administrator rights may also cause this problem. The error message dialog has been suppressed in K-3D 0.6 since the Python script engine (like all K-3D plugins) is optional functionality and failure to load a plugin due to missing dependencies is not considered an error condition.

"ERROR: Module [...libk3dpython.dll] could not be loaded: error 126"

This the same error as above, but the message appears in the console (assuming K-3D was run from an open console). The error is harmless unless you want to use K-3D's Python script engine. Try running the K-3D all-in-one installer, which includes Python 2.4, or install (or reinstall) Python 2.4 manually. We have anecdotal evidence that using the Python installer without administrator rights may also cause this problem.

"The procedure entry point XML_SetDoctypeDeclHandler could not be located in the dynamic link library xmlparse.dll"

Summary: xmlparse.dll and xmltok.dll are libraries that are part of the GTK+ library distribution on Win32. Apparently (and unfortunately) there are several different versions of xmlparse.dll in circulation on Win32. It appears that some software incorrectly installs copies of these two libraries in the system32 folder. This is the cause of the problem, because the system32 folder should never contain libraries from third parties (it should only contain files that shipped with the operating system). Remove xmlparse.dll and xmltok.dll from the system32 folder, so the ones that come with K-3D are used instead.

Tor Lillqvist, the originator of GTK-on-Win32 writes:

xmlparse.dll is the other one of the DLLs in the expat library's Win32
binary as distributed from ftp.jclark.com/pub/xml/expat.zip (the other
one is xmltok.dll). There apparently are several different versions of
xmlparse.dll floating around, or perhaps even a totally unrelated DLL
with the same name?

Presumably one of those has been installed in your Windows system32
folder by some broken software (*nothing* other than what is shipped
with Windows should be installed in the system32 folder).

Remove xmlparse.dll from the system32 folder, so that the one you got
with GIMP gets used instead.

BTW, on my machine, I seem to have a version of expat where the DLL in
question is called "libexpat.dll". I don't recall right now where I
got that from, or whether I built it myself.

This kind of confusion is not uncommon in the world of Free and Open
Source software for Win32. They typically occur when the "official"
way to build for Win32 is with MSVC and the package's official sources
provide MSVC makefiles that produce a certain DLL, but if you build
using autofoo and libtool instead you get another name. Then different
people distribute binaries built in the two (or even more)
ways. Well-known cases are gettext-runtime (intl.dll vs. libintl3.dll)
and libiconv (iconv.dll vs. some libiconv*.dll.)

John McCulloch <waldomacusa@yahoo.com> writes:

I looked high and low in Dependency Walker's paths and
extended paths, etc., and found no call for
xmlparse.dll, so I did some digging and found that
GIMP users have had this come up a lot.

Several boards had persons who advocated replacing
both xmlparse.dll and xmltok.dll in the
Windows\system32 folder with the newer and slightly
larger versions in GTK. I created a new folder in
Windows\system32 and named it xmlparse_old. I placed
the old files there, just in case and put in
xmlparse.dll and xmltok.dll from GTK.