• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

P3D v5 Remote debugging using VS2019

DragonflightDesign

DragonflightDesign

Resource contributor
Messages
1,371
Country
northernireland
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.
 
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...
 
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.
 
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.
 
You must log in or register to reply here.
Back
Top