Invoking P3D v4.1 with an invalid command-line argument breaks SimConnect

[adiemus]

This seems to be related to the issue I posted here: http://www.prepar3d.com/forum/viewtopic ... 1&t=127900

If I invoke P3D v4.1 with a bad command-line argument, ala:

Code: Select all

c:\path\to\Prepar3D v4>Prepar3D.exe -badarg

then SimConnect behaves differently than if no bad command-line argument was passed. Specifically, the issue seems to be related to displaying the dialog telling me that the requested scenario (which P3D falls back to assuming "-badarg" should be interpreted as) is invalid. (Similar to my other bug report, linked above)

When no command line argument is passed, my module can call SimConnect_MapClientEventToSimEvent() without issue. However, if the bad argument is passed, the same module making the same SimConnect calls now has several of them return SimConnect Exception 7. (Ultimately meaning that there is no way to access several SimConnect events if an invalid command-line argument was specified when running the sim)

Here's a SimConnect log excerpt showing the issue: (using 'quote' rather than 'code' tags as 'code' tags seem broken for multi-line text)

> 14.08675 [ 2, 314]MapClientEventToSimEvent:EventID=68, EventName="ADD_FUEL_QUANTITY"
< 14.08675 [2] >>>>> EXCEPTION=7, SendID=314, Index=2 <<<<<
> 14.08676 [ 2, 315]AddClientEventToNotificationGroup:GroupID=6, EventID=68, bMaskable=1
< 14.08676 [2] >>>>> EXCEPTION=3, SendID=315, Index=2 <<<<<
> 14.08676 [ 2, 316]SetNotificationGroupPriority:GroupID=6, uPriority=10000000
> 14.08677 [ 2, 317]MapClientEventToSimEvent:EventID=69, EventName="REPAIR_AND_REFUEL"
< 14.08677 [2] >>>>> EXCEPTION=7, SendID=317, Index=2 <<<<<
> 14.08678 [ 2, 318]AddClientEventToNotificationGroup:GroupID=7, EventID=69, bMaskable=1
< 14.08678 [2] >>>>> EXCEPTION=3, SendID=318, Index=2 <<<<<
> 14.08678 [ 2, 319]SetNotificationGroupPriority:GroupID=7, uPriority=10000000
> 14.08679 [ 2, 320]MapClientEventToSimEvent:EventID=70, EventName="TAKEOFF_ASSIST_ARM_TOGGLE"
< 14.08679 [2] >>>>> EXCEPTION=7, SendID=320, Index=2 <<<<<
> 14.08679 [ 2, 321]AddClientEventToNotificationGroup:GroupID=10, EventID=70, bMaskable=1
< 14.08680 [2] >>>>> EXCEPTION=3, SendID=321, Index=2 <<<<<
> 14.08680 [ 2, 322]SetNotificationGroupPriority:GroupID=10, uPriority=10000000
> 14.08680 [ 2, 323]MapClientEventToSimEvent:EventID=71, EventName="TAKEOFF_ASSIST_ARM_SET"
< 14.08681 [2] >>>>> EXCEPTION=7, SendID=323, Index=2 <<<<<
> 14.08681 [ 2, 324]AddClientEventToNotificationGroup:GroupID=9, EventID=71, bMaskable=0
< 14.08682 [2] >>>>> EXCEPTION=3, SendID=324, Index=2 <<<<<
> 14.08682 [ 2, 325]MapClientEventToSimEvent:EventID=72, EventName="TAKEOFF_ASSIST_FIRE"
< 14.08683 [2] >>>>> EXCEPTION=7, SendID=325, Index=2 <<<<<
> 14.08683 [ 2, 326]AddClientEventToNotificationGroup:GroupID=9, EventID=72, bMaskable=0
< 14.08683 [2] >>>>> EXCEPTION=3, SendID=326, Index=2 <<<<<

Taking the first entry as an example, exception 7 is SIMCONNECT_EXCEPTION_NAME_UNRECOGNIZED, which suggest that the first line of that excerpt fails because the name "ADD_FUEL_QUANTITY" is unrecognized. But clearly this is incorrect, as it's not only in the SDK (going back to FSX) but also works just fine if P3D is invoked without the invalid command-line argument. (The above excerpt is but a small sample of the SimConnect mis-behavior observed in this case)

(NOTE: The Exception 3 responses to the AddClientEventToNotificationGroup() calls make sense after the Exception 7's since the client event never got properly mapped so it doesn't exist to add to the notification group. I expect fixing the Exception 7 issue will resolve the Exceptin 3's)

Between this and my earlier thread, there seems to be some sort of dependency between command-line processing of invalid argument (or managed P3D themed dialog display code) and SimConnect.

I've uploaded a minimal VS2015 DLL Module project that will reproduce the problem. You can find it here:
https://forums.vrsimulations.com/downlo ... odule2.zip
Compile it and add the resulting DLL to your dll.xml to load it. Invoke the sim with an invalid command-line argument to see the problematic behavior.

[adiemus]

Given the timing of my initial report, perhaps this got missed due to the holidays, but it seems critical enough to warrant bumping it.