I've got a D3D9 application, which works fine on my machine. But when I send it to a friend, his machine won't render any of the 3D content. I already changed the build to enable all error-code checking and they all come back clean. How can I remotely debug why his machine's rendering is broken?
-
\$\begingroup\$ are you sure that the models where packaged with the exe, or they might have been left separate. the only way to test this would be to compress the 3D art assets, and then go to play the game, and see if the same result happens. \$\endgroup\$– gardian06Commented May 6, 2012 at 17:49
-
\$\begingroup\$ @gardian06: I don't have any independently packaged art assets. All the resources are in the same place- and the game would not load at all if it could not find the shaders, etc. \$\endgroup\$– DeadMGCommented May 6, 2012 at 18:00
3 Answers
Here is something that may help.
Ask your friend to install the DirectX SDK, then launch the DirectX control panel. From there, select the debug runtime. Finally, tell your friend to launch PIX (included in the DirectX SDK, too) and record a whole frame of your program, then save the result and send it to you. You can run PIX locally in order to guide your friend around the software.
You can then replay the PIX stream on your box and you should get verbose information about what is happening.
Also, it is possible that running PIX on your own machine will tell you what your program is doing wrong.
Visual Studio does support remote debugging in the non-express editions. Instructions for setting it up are here: http://msdn.microsoft.com/en-us/library/bt727f1t.aspx
On top of that you'll need some method of seeing the screen and speaking to your friend. I'd go with using Skype with their webcam pointed at their screen.
-
\$\begingroup\$ VSMON is likely the best solution. Log Me In Hamachi might also makes things much easier - I don't know how compatible VSMON is with the internet. \$\endgroup\$ Commented May 7, 2012 at 13:48
-
\$\begingroup\$ You can share your screen with Skype. \$\endgroup\$– TiliCommented May 7, 2012 at 14:25
-
\$\begingroup\$ @Tili VSMON is not a screen-sharing tool: it allows you to debug a process on a remote machine, as though you were running it locally. Hamachi would be used to make it think it was running on a LAN because I have never personally used it over the internet: so I can't vouch for its compatibility there. \$\endgroup\$ Commented May 7, 2012 at 14:49
What steps have you taken, "enable all error-code checking" means nothing to us without knowing what errors you are checking or how. What exactly happens on your friend's machine and how is it different from when you run it, where do the differences show up?
Have you tried running the exact same files on your machine, but NOT in your development environment and from a freshly create directory? You need to do this to verify that all the files needed are present in the package and in the right place before going any further.
A common problem is only running the Debug version and then shipping a Release build, have you tried running the same build type that you send to your friend? Remember that Release will not zero-out allocations and this will cause some D3D initializations to do odd things because of the junk values in the parameter structures.
Look through your code, what could cause models to not render? Are the buffers created from the models NULL and the render is simply skipped, verify that kind of logic.
Do you check D3D device caps to see if it supports features you need? Are you simply choosing the primary device, or do you have a selector to choose which device?
Add logging to a text file, track your startup sequence and important loop events.
Do you track your models loading? How do you know that your models are loaded?
Does everything else work, do you have a HUD or any kind of other rendering in your D3D window that's working just fine or is all rendering broken?
So much can be done to log what's happening and debug locally before trying to find a remote, and more difficult method.
-
1\$\begingroup\$ also take an extra step, and include fileIO so that specific event can be logged \$\endgroup\$ Commented May 7, 2012 at 1:33
-
1\$\begingroup\$ I hate to -1 an answer that you have clearly put a lot of effort into: but part of my responsibilities in my day job is debugging (crash analysis). Speculative debugging falls into the same realm as premature optimization - basically your debugger is the analogue of a profiler. It's best to measure first and if that comes up with nothing then venture into speculative measures: or you could land up wasting quite a bit of time. \$\endgroup\$ Commented May 7, 2012 at 13:58
-
\$\begingroup\$ I understand. But take a look at the steps I propose, the steps do in fact add remote data capturing so he can get to what you suggest - measure first. Is he using the same code+data verification. Do some rubber ducking. Is he following proper D3D procedures. Add logging, and especially to fileIO. Describe the problem more clearly so we can help better. Those are all simple to implement precursors to establishing a complicated, remote debugging session that an obviously new programmer would have much more difficulty with. I targeted my audience, basically. \$\endgroup\$ Commented May 7, 2012 at 15:08
-
\$\begingroup\$ @JonathanDickinson +1 because you make a great point about debugging not often seen here. \$\endgroup\$ Commented May 7, 2012 at 15:11
-
\$\begingroup\$ Given your justification I would +1 your answer, unfortunately I can't as 18 hours have passed :(. \$\endgroup\$ Commented May 8, 2012 at 9:34