3
\$\begingroup\$

I have a c++ application which outputs to screen using entirely DirectX9, running on Win7 64 Home.

It runs as normal in these circumstances:

  • Debug Build, from within MSVC 2008.
  • Release Build, from within MSVC 2008.
  • Debug Build, by opening the compiled executable itself.

However, strange things happen when I run the compiled executable of the release build. The window is created as expected but no screen output. Nothing.

I can hear the sound working and the log file fills up. I thought maybe the working directory was wrong when running the executable but the log file reports the CWD is correct and indeed all filepaths to data files work.

I am stumped as to why my application will work fine in 3 of the four permutations, but not the most important one - the standalone release executable!

If anyone can contribute, I'd be most grateful.

Thanks

Si

Improve this question
\$\endgroup\$
0

4 Answers 4

Reset to default
2
\$\begingroup\$

Attach the debugger to the version not started from within VS, and debug through to see what is going on. To help you catch the early part of the program, you can put a dialog box or __debugbreak into the early part so you can attach early and see the DX surfaces being created and so on.

Martyn

Improve this answer
\$\endgroup\$
3
  • \$\begingroup\$ Thanks for the advice. Unfortunately as I already mentioned, the debug version works well from within MSVC and as an exe. Attaching to the release exe doesnt show me anything, as it is not built with debug info. \$\endgroup\$
    – sipickles
    Jul 9, 2011 at 20:25
  • 1
    \$\begingroup\$ So you should enable building debug symbols for the release build [this is enabled by default in the IDE]. You can then debug the release one. Code generation is not impacted by building PDBs. \$\endgroup\$
    – Martyn Lovell
    Jul 9, 2011 at 21:56
  • \$\begingroup\$ Follow Martyn's great advice and realize that you can use the debugger on anything, even running executables not built in "debug mode." If you've turned on the symbols you can even load the EXE in the debugger and set breakpoints before you start the run. \$\endgroup\$
    – Patrick Hughes
    Jul 11, 2011 at 16:24
2
\$\begingroup\$

the difference between running with the IDE attached at startup is usually that the state of the memory handed to you by the allocator is not the same. If I remember correctly, it's zeroed out or filled with garbage (I can't rememeber which as we don't use standard allocators any more).

Checking memory should be your first approach vector. Make sure all your allocations assume that the memory is dirty and initialise them.

Improve this answer
\$\endgroup\$
0
\$\begingroup\$

Please use DirectX SDK Utilities - DirectX Control Panel and see if you are not getting an error.

Set Debug level in control pannel, recompile your application and you should see runtime errors in the Output window

Improve this answer
\$\endgroup\$
0
\$\begingroup\$

Build your program with the highest warning level turned on, see if it catches any uninitialized variables.

Make sure that you're checking all return values from system calls.

Follow the advice to use the debug DirectX/D3D driver and watch its output to see what changes between the working code and the broken.

Improve this answer
\$\endgroup\$

You must log in to answer this question.