Member Avatar for ilyaz

I have a C++ console executable module build in VS2008. To run it requires some MS components to be installed, namely:
-- Visual C++ 2005 Redistributable Package
-- Window Media Encoder 9 Package
The module runs fine on all XP machines I tried but fails to load on a Windows Server 2003 R2 box (more precisely MS Windows Server 2003 R2 Standard Edition SP2). When it fails to load, it produces a very generic error message which gives me no clue as to what is actually going on. The very 1st statement in the module is a printf so since nothing gets printf'd, it seems that the problem might be with one of the above components the module depends on.

Do you to know if there are versions of these modules specifically for MS Windows Server 2003? What else could be going wrong?

thanks much!

  • 2 Contributors
  • 4 Replies
  • 116 Views
  • 8 Hours Discussion Span
  • Latest Post Latest Post by ilyaz

Dani AI

Generated

's advice to run a dependency analyzer was exactly the right direction, and confirming it fixed the problem matches a very common class of failures. When the first printf never executes the fault usually happens at load time: the loader can't find a required DLL, a Side‑by‑Side (SxS) manifest/runtime mismatch prevents CRT activation, there is a bitness mismatch, or static/global initialization crashes before main.

A compact, practical checklist (run these on the target machine):

dumpbin /dependents MyApp.exe
mt.exe -inputresource:MyApp.exe;#1 -out:MyApp.manifest
  • dumpbin shows the static imports; look for any DLL names not present on the server.
  • mt extracts the embedded manifest so the exact SxS CRT/assembly version and processor architecture can be inspected.

Next-level traces: use the dependency tool's profiling feature (the profiling run shows delay-load and load-time failures), and run Process Monitor (filter by process name) while launching the EXE. In ProcMon look for DLL load attempts that return NAME NOT FOUND or ACCESS DENIED. Also check the Application/System event logs for SideBySide or loader errors — those entries often include the exact assembly name and version causing the failure.

Resolution patterns and cautions: install the runtime/redistributable that matches the compiler and bitness used to build the EXE, avoid shipping debug builds (they depend on non-redistributable debug CRTs), or build with the static CRT (/MT) if redistribution is undesirable (note the trade-offs). Do not “fix” SxS by casually copying CRT DLLs into the app folder unless the manifest and SxS rules are understood. For third‑party SDKs register or install their official redistributables on the server.

Collect the dumpbin output, exported manifest and a ProcMon trace — those artifacts give a definitive root cause for any remaining mystery.

Recommended Answers

All 4 Replies

Member Avatar for Ancient Dragon

The program depends.exe distributed with the compiler will tell you all the DLLs that are required by your program. Probably one or more of them are missing or the wrong version.

commented: A good suggestion. +5
Member Avatar for ilyaz

The program depends.exe distributed with the compiler will tell you all the DLLs that are required by your program. Probably one or more of them are missing or the wrong version.

Thanks. Does this tool give info on what DLLs are broken or wrong version?

Member Avatar for ilyaz

It worked, thanks!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.