P3D v5 Remote debugging using VS2019


Resource contributor
Has anyone tried remote debugging a c-gauge? The problem I have is that the gauge works on the development machine and crashes when on a new build O/S. 'Dependencies' (replacement version of Dependancy Walker) doesn't show the dll calling something that's missing, so that counted out the obvious. I can hook P3D (4 or 5) on the clean machine with the remote debugger but the breakpoints are never hit. Inspection of the loaded modules shows a bunch of Lockheed-Martin stuff but no gauge dlls (OEM or mine) ever show up. So... not surprised that the breakpoints aren't being hit. I'm not going to list everything I did - that's way too many hours of my life I'm not going to get back - I'm asking a direct question; if you succeeded, what settings did you have for the remote debugger and what settings did you have in the debugging sections of the VS configuration manager?

If it isn't possible, I'm going to have to learn to read procdump files... :banghead:
I use it all the time. I use "Attach To Process". I tell the IDE to use native debugging, not managed. Based on your post, you are not getting the DLL loaded at all. To chase that, I would have the IDE running with the code... I would start the sim up and select the desired flight but NOT load it yet. I would then attach to the sim's process via the remote (no authentication) method. Once attached, I would have the sim load the flight.


Resource contributor
I'll have to get back to you on that one Ed. I've broken things so badly trying to get a remote connection that (as I've just discovered) I can't debug locally any more either (sigh). There are times...


Resource contributor
Update: I'm beginning to seriously hate VS2019. After at least another five-six hours which included

- rebuilding the solution from scratch
- copying in a P3Dv4 solution from VS2017 that did work and then changing it to look at P3Dv5
- a whole load of other stuff

I was finally able to debug locally again. How did I fix it?

- Attach to process
- Select 'Attach to' (just to check it really did just say only 'Native' in the checkboxes as well as being the default display)
- Cancelled the dialog without doing anything (note: cancelled it)

and the bleeping thing promptly hit the breakpoint. :banghead: :banghead: :banghead: :banghead: AAARRGHHHHHHHHHH!!!!!!!!!!!!!!!!

So, back to remote debugging. Your tip on loading the aircraft into the scenario dialog and then starting the debugger worked... but no symbols loaded. Funny - I know fine well that the dll and the pdb are the same versions because I just compiled the project and copied the dll across. Tried to force-load the pdb file - 'No matching symbols'. Recompile and try again. Same result.

Checked the details on the remote dll. Whddya mean it's dated 20th June!!!!!!!!!!!!!!

So the operating system has been lying to me. It didn't really copy the dll across at all, despite me

- mapping a remote drive back to the host PC
- manually moving the dll from the mapped drive to the aircraft/panel folder
- the operating system telling me 'yes, I've just copied it there for you' by showing the nice floaty white copy icons, deleting the dll from the mapped drive and no error message

No you bleep-bleep-bleeping well haven't. Then I remembered Symantec anti-virus doing this to us at work when copying stuff across the network... Engage the same solution and see what happens.

- move the dll from the mapped drive to the desktop
- move the dll from the desktop to the /panel folder

Now the dll displays the correct date under the 'Details' tab and the ##%%## symbols decide to load.

Apart from this being a semi-cathartic rant, I put all this down in case someone else hits a similar problem.


Resource contributor
I should really have said 'internet security software' but it amounts to the same thing. If I'd had a blood pressure monitor attached to my arm at the point that the remote breakpoint was hit, I'm sure I'd have won some form of competition for the fastest drop in blood pressure over zero seconds.