6

I've been running and compiling a program on my Windows 7 64-bit machine for several months now, but recently I had to change several VC project settings of the static libs that it uses and now the generated executable file requires me to run it in "Windows XP Compatibility Mode".

  • Compiled on Windows7 64-bit machine with Visual Studio 2010 SP1
  • The program I am generating is being built in Win32, debug mode.
  • The static lib projects specify Target Machine /X86.
  • When I run the program from the debugger, it start up and runs, however if running via the windows icon, it requires XP compatibility mode.
    • When trying to start outside of the debugger the EXE shows up in task manager for a second then goes away.
  • I've tried using Microsoft Application Verifier on it, however I don't know what to look for in the output.

I've been unable to find any details on how to troubleshoot this issue so if anyone has any ways if finding what could be causing this recent Compatibility Mode requirement I'd love to hear how it was fixed.

I have the source/projects/solutions for the majority of the static libs that I link against, as well as the exe file generated, however some of the external dependencies I only have the .lib,.dll, and .h files for. This means I can change (most) of the project settings for the dependencies if neccessary, but I need to know which ones to look for.

Thanks

Mciccarone
  • 111
  • 1
  • 3
  • You'll need to do a better job describing what goes wrong when you don't turn on compat mode. – Hans Passant Sep 05 '12 at 14:59
  • When I run using non compatibility mode the EXE simply shows up in task manager for a second, then goes away. – Mciccarone Sep 05 '12 at 15:28
  • Nothing is printed in the Windows Event Log, the constructors are not called, even the main() is not called upon start – Mciccarone Sep 05 '12 at 15:29
  • What is the exit code of the process, displayed in the Visual Studio Output window when you start debugging by pressing F5? – Hans Passant Sep 05 '12 at 15:31
  • all of the thread exit codes are (0x0) with Visual Studio. – Mciccarone Sep 05 '12 at 16:28
  • You don't have old copies of the static library `.vcpxroj` files to compare against (they should be in source control...). – Michael Burr Sep 07 '12 at 05:47
  • Monitoring the program start up with something like Sysinternals' Process Monitor might show something helpful; maybe if you compare a run without the XP compatibility setting and one with, there will be an obvious difference. – Michael Burr Sep 07 '12 at 05:51

1 Answers1

1

To be honest, don't be afraid to make another project and copy the code files, even if it's 5 projects. You need to cut the problem in half. If it works with the new projects then it's the project files, if not, it's the code. Making projects isn't that hard really, though I'm sure a source of much consternation and something people avoid. If its the projects you can diff the files and see what happened by process of elimination. If you are really worried, copy the entire solution to another folder; always make backups.

The problem is that you probably won't be able to hoist enough information up to us to get a meaningful answer unless get lucky, and all the answers will be shots in the dark.

So I'm goign to take this question as "this happens, what can I do about it". The strategy above will get you out of it, if this used to work before. This exercise will arm you for the future and will be more productive in the long term. Go look at UAC and manifest files, aka Vista+ difference tht dramatically changes load and run behaviour (Linker Commands, Vista Migration Guide) if you need one thing to look at, but try the above process.

----

Other generic things to try:

1) another machine

2) another install of VS

3) a simple project with one window that does nothing to prove everything else in your tool chain and environment is ok.

4) planting message boxes along the code path with different messages so you know where its crapping out.

5) turing on pdb in release and runnign outside of debugger. If craps out, then try debugging and see if still craps out, but you get to see where.

6) assume that your code is unstable and you were getting lucky when it used to work. (this one is no fun). Many times things work in debug and not in release due to mem layout being different. If your progam is large you can find creative ways to use #if's whatever to elimitate code from running while haivng the whole thing still load. You can find the code that causes the bad behaviour.

7) turn off UAC and error reporting if its on, see if changes.

8) go find the "run without debugging" menu button in Visual Studio, so you don't have to go run it with the icon. That's an accident waiting to happen, and eliminates one more environmental difference. It looks like the run with debugging button, but it's hollow, a plain green triangle. It's under debug menu set. My oppinion is that it has done more harm than good to not have that on the bar by default as its confused many many people to think launching wiht VS means always using the debugger.

and so on....

harper
  • 13,345
  • 8
  • 56
  • 105
Beeeaaar
  • 1,010
  • 9
  • 19
  • Hi Celess, I've done many of the steps you suggested already (Disable UAC, pdb works in release, string print outs in the code paths ). I have noticed that the compatibility mode works for selected OS ranges from Windows 2000 all the way up to Vista Service Pack 2. I would try Win7, but that isn't available in the drop down list. – Mciccarone Sep 07 '12 at 17:06
  • So when you enbled pdb in release, it started working again when run outside the debugger? Like the app stays up? – Beeeaaar Sep 07 '12 at 18:21