Timeline for How to remotely debug a D3D9 application
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 8, 2012 at 9:34 | comment | added | Jonathan Dickinson | Given your justification I would +1 your answer, unfortunately I can't as 18 hours have passed :(. | |
| May 7, 2012 at 15:11 | comment | added | Patrick Hughes | @JonathanDickinson +1 because you make a great point about debugging not often seen here. | |
| May 7, 2012 at 15:08 | comment | added | Patrick Hughes | 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. | |
| May 7, 2012 at 13:58 | comment | added | Jonathan Dickinson | 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. | |
| May 7, 2012 at 1:33 | comment | added | gardian06 | also take an extra step, and include fileIO so that specific event can be logged | |
| May 6, 2012 at 23:06 | history | answered | Patrick Hughes | CC BY-SA 3.0 |