简体   繁体   中英

Program compiled with MSVC 9 won't start on a vanilla SP3 XP

I installed XP on a virtual machine, updated it to SP3 and then tested a small program compiled with Visual C++ 2008 on my real computer - however it didn't start but outputted only an error saying that a problem had been detected and that a reinstall of the application (mine is 10KB in size and doesn't even have an installation) could fix the problem.

  • What is required to run programs compiled with MSVC 9?
  • Can I just include some dlls for it to work everywhere?

Either link statially against the runtime library (select multithreaded instead of multithreaded-dll ) or follow tommieb75's advice and install the MSVC9 runtime redistributable (copying to system32 or to the application's folder works as well, but is not the way to go, afaik). For small applications with no need for an installer, I'd prefer the first option. Deploying runtime installers is annoying .

您可能会缺少MCVC9运行时库,请尝试将其复制到Windows System32文件夹中。

It may depend against which DLLs your project is linked. Inspect the assemblies manifest and check if those DLLs are installed on your VM.

What does your program contains? Dependencies on dynamic C/C++ runtime ? Then you need to either include the C++ redistributable runtime DLLs in your app, or change the program to use the static C++ runtime. Similarly, do you use ATL? MFC? Custom 3rd party libraries? They all add dependencies to your executable and Win32 will refuse to load your application.

One easy step is to check with Dependency Walker what dependencies your application has.

It could be a dll you application links against. The depends tool is a must have in every programmers toolbox for debugging dll dependency issues.

If you have the commercial rather than express msvc edition, what you really should do is copy the msvcmon redist components to your VM, run the remote debug monitor there, and attach to it from your desktop dev environment. This page explains the basic principal. Because it sounds like your app is causing an exception on XP.

If you can't remote debug and if dependency checker does not indicate a dll issue, then you could look in the systems application event log to see if there is any more information there. Or try install Dr Watson as a post mortem debugger. Open a command prompt and enter

drwtsn32 -i

to install Dr Watson as the post mortem debugger, and

drwtsn32

to get a config screen allowing you to browse for the location of crash dumps. You can load crash dump files directly with Dev Studio 2005 and later. (I don't think Dr Watson ships with Vista and Windows 7 anymore).

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM