Jump to content
  • Advertisement


This topic is now archived and is closed to further replies.


Using the DirectX Debugger

This topic is 5987 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I heard there was a debugging tool that came with the DirectX SDK, problem is I can''t figure out to use it. Can some either point me to a link that show me how or show me how themselves??

Share this post

Link to post
Share on other sites
Only thing I could find was the error lookup tool. Someone had something that analysed my d3d code well enough to tell me that my drawprimitive calls were redundant due to a previous error which it also spotted. What would that be - it output a big list of all d3d function calls and details of what happened.

Read about my game, project #1

John 3:16

Share this post

Link to post
Share on other sites

Look in the DXSDK\DXUtils\bin\ folder for dbmon.exe. Run that (I can''t remember whether or not it requires Win2k), when the DirectX runtimes output to the debug stream, those messages will be output in the window dbmon opened. Nothing more to it!.

If you''re using MSVC and you build your app as a debug build, use the debug SDK (see past posts here for how) and press F5, exactly the same information will be output to your MSVC window!.

An alternative and more fully featured program is DebugView which is free to download from www.sysinternals.com


If that was me (I''ve done it a few times here) I''ll list a few of the pieces of special equipment I have in my doctors bag :

A couple of handy tools to seek out:
1. DLL Detective (by Adam Moranvansky IIRC)
2. GRAZ (by Herb Marselas/Ensemble Studios)

Also some which are handy when it comes to profiling and digging:
1. IPEAK GPT (commercial app from Intel [incidentally originally developed by Herb when he was at Intel]. Less useful these days since it was discontinued with DD7/D3D7/OGL1.1).

2. VTune (commercial app from Intel - v. useful to see what other processes/DLLs have contributed in a frame of your app).

3. The free program like a mini VTune from AMD which I''ve forgotten the name of...

4. The new version of Dependency Walker available in the Platform SDK since it now does dynamic dependencies (v.handy!)

5. nuMega TrueTime - commercial product, similar idea to VTune.

6. nuMega SoftICE - commercial product, for the real hardcore stuff - a bit of a case of using a sledgehammer to crack a nut for most application debugging. But is the best way of getting in and having a real sniff at what happens at and below the Windows Kernal and driver - and of what caused the real serious machine wipeout crashes. 99.99% of the time you should be able find/fix problems without going down to that level.

7. nVidia nVTune, profiling drivers etc, and similar from most IHVs - special tools usually only available to registered developers. They tell you stuff about what''s being passed from D3D to the driver and how happy the driver is about what you''re doing.

As well as those, I''d say always use the SDK debugging features as much as possible (the debug levels, the break on error etc). On top of that, at your code level, make extreme use of asserts, and things to check return codes (I posted our TRYDX() macro in response to someone else here, it may be worth using). With good debug build code we catch most bugs as soon as the bad code is implemented - well before there is a D3D problem to track down.

Simon O''Connor
Creative Asylum Ltd

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!