We took action and investigated the issue on the user’s machine. The bad news is that an actual debugger needs to be attached to the process for these messages to be emitted. The good news is that activating this feature only takes setting a global flag. In cases like this, making the loader emit verbose diagnostic messages comes in handy. The stated DLL was present and intact, so the error made no sense. I remember a technical support case where one of our users reported that after successfully installing our product, it failed to start because of a DLL that was reported to be missing. Sometimes, however, the stated error message doesn’t make much sense (for example, it complains about the wrong binary). If a program can’t start because a static DLL dependency cannot be loaded (maybe it’s missing, or damaged etc.), you get a helpful error dialog stating the name of the affected DLL, which gives you a decent pointer on fixing the issue. In this post, I’ll reason about why you shouldn’t settle for merely detecting whether this dependency is installed, with two real-world examples. When your product is installed, you (or the installer framework you use) have to make sure that the appropriate version of the redistributable is also installed, or your program will fail to start. Chances are that you link your binaries against the dynamic runtime DLLs, which means that your application has a runtime dependency of (at least some of the) DLLs contained in this redistributable package. If you ship software on Windows written in C++ and compiled with the MSVC toolchain, then you probably heard about the so-called “Visual Studio C++ Redistributable”. TL DR: It’s worth not just detecting, but also trying out whether it actually works.
0 Comments
Leave a Reply. |