aurel42

Hi, when I connect my yoke to my system, FSUIPC cannot "see" my pedals any longer. The pedals are working when I look at them using the Windows "Game Controllers" dialog. [JoyNames] AutoAssignLetters=No Y=CLSE NG Yoke Y.GUID={BBAB7FA0-EC23-11E9-8003-444553540000} J=Joystick - HOTAS Warthog J.GUID={BBAB5890-EC23-11E9-8001-444553540000} T=Throttle - HOTAS Warthog T.GUID={BBAB7FA0-EC23-11E9-8004-444553540000} 0=CLSE NG Yoke 0.GUID={BBAB7FA0-EC23-11E9-8003-444553540000} 1=Joystick - HOTAS Warthog 1.GUID={BBAB5890-EC23-11E9-8001-444553540000} 2=Throttle - HOTAS Warthog 2.GUID={BBAB7FA0-EC23-11E9-8004-444553540000} P=<< MISSING JOYSTICK >> << MISSING JOYSTICK >> A=<< MISSING JOYSTICK >> << MISSING JOYSTICK >> B=<< MISSING JOYSTICK >> << MISSING JOYSTICK >> (P are the pedals, A is a custom throttle quadrant I removed after the problem started, B is another "instance" of the yoke (Y) that showed up temporarily during testing) If I read the log correctly, the pedals and the Warthog joystick are using the same GUID. I tried a couple of things, among them: removing all the USB HIDs and Game controllers in the device manager, disconnecting rarely used devices (gamepad, Bodnar-based throttle quadrant), reconnecting the active devices to different USB ports, starting FSUIPC with an empty JoyNames section, and rebooting a lot between steps. Any idea what could be wrong, any advice? Thanks, Marc FSUIPC7.JoyScan.csv FSUIPC7 - Copy.log FSUIPC7.ini

Testing was a bit delayed by the arrival of 1.10.11.0. 🙂 1.10.11.0 + 7.0.0: no controls after MFS restart 1.10.11.0 + 7.0.1a: working controls after MFS restart Thanks, John! ❤️ Note that 7.0.1a stopped logging while it was still running. Possibly because I opened the logfile with an editor? Not sure how write locks work in Windows. FSUIPC7.log

I removed everything from FSUIPC7.ini that didn't seem relevant to how I use it, and restored the [Auto] section MFS was still running, I started FSUIPC, controls free & correct I restarted MFS, no controls, empty line in log At this point, I have no idea why you wouldn't see the issue as well. I'd be happy to test with a FSUIPC binary with extra logging or whatever. (I'm following this thread, so let me know here when you find the time, please.)

I believe the problem is reproducible on my system: when MFS quits to desktop, FSUIPC "hangs" in some form or other; when MFS crashes to desktop (it happens much less often than before, but even with 1.10 it sometimes happens on my system), FSUIPC will keep working. Started FSUIPC, started MFS, started a random flight from World Map, control check: free & correct, returned to Main Menu, Quit to Desktop restarted MFS, random flight, control check: no controls (at this point, I would usually restart FSUIPC and commence flying), returned to Main Menu, Quit to Desktop, quit FSUIPC (File / Exit), removed [Auto] section from FSUIPC7.ini restarted FSUIPC, restarted MFS, random flight, control check: free & correct, rotaries do nothing (so the lua appears to be deactivated), returned to Main Menu, Quit to Desktop Started MFS, random flight, control check: no controls, restarted FSUIPC, controls free & correct Dammit. Tbh, I totally expected the controls to work in step 4. The "empty" line in the log appears to be the signature of the problem. Whenever I lose control inputs, I see that empty line.

I'll do some testing and report back!

Sure, just reporting that removing the cruft did not actually fix the issue, so I wouldn't provide misleading information. As I mentioned in my original post, I don't like the use the bat, because I don't like the "Preparing the cabin" image (I'm generally not fond of "startup graphics" appearing on the desktop, just a matter of taste), and I got my flow starting all the tools I need. I don't need to restart any of my other tools (LNM, TrackIR, FSE client, Navigraph…) when I restart the sim (e.g. when modifying or updating mods, or when I suspect that the sim has entered an unstable state), so it would be nice if I didn't have to restart FSUIPC either. Take your time, but just keep in the back of your head that different people have different preferences and ways they like to do things. 😄

I was too quick to report back. I've seen the same issue today: I quit MFS last night, let the PC (incl. FSUIPC) run because I was downloading liveries. This morning, I started MFS and had no controls (until I restarted and registered FSUIPC). Not 100% sure, but my impression is that FSUIPC is only misbehaving when I quit MFS and the application exits "cleanly". When MFS crashes, FSUIPC behaves as expected and does not have to be restarted.

After removing the cruft, I have not seen another instance of FSUIPC misbehaving.

Hi, starting with the previous version released on Oct, 3rd, FSUIPC is often misbehaving on my system when I restart the sim while FSUIPC is running. I've seen it become unresponsive once. Quite often, I experience lack of controls in MFS until I restart FSUIPC. When testing with the Axes or Buttons dialogs in FSUIPC in this situation (before the restart), all controls appear to be working fine, but they don't have any effect in MFS. I don't use the wrapper script (I don't like the "preparing the cabin" thing), I'm always starting FSUIPC and MFS separately. Note the "empty" line at timestamp 845953 in the attached log file. Cheers, Marc FSUIPC7.ini FSUIPC7_prev.log

I started MFS earlier today and forgot to remove the input profiles, and yet it worked. I have no idea what's going on there. But I guess soon it'll be moot, since a Hotfix appears to be incoming:

Funny story: I wasn't aware that I was supposed to disable Steam Cloud Synchronisation. And, indeed, after I deleted the input profiles, I could see them being restored just before the actual MFS process was launched by Steam. And, yet, even though it makes no sense at all, removing the files (albeit only temporarily) seemed to solve the issue for me. There is one other change to my setup which could have had an effect: I know that my CH Pedals were part of the problem, because, when I had all other devices disconnected and plugged in the pedals, MFS crashed immediately. I had used an USB port on the mainboard for the pedals, but I had to get up from my comfortable chair to plug and unplug them. I decided to plug them into an easily accessible USB hub instead. That could've been right around the time that I got the advice to remove the input profiles. I might have violated the basic debugging principle "one change at a time" there. Another explanation for the difference between your and my situation could be that whatever is causing the crash (perhaps a specific assignment or type of assignment or a specific sensitivity setting – they DID change something about the sensitivity setup according to the patch notes) is already present in the default input profile for your device(s) that trigger(s) the crash, so even with all custom profiles deleted, the sim reads the default profile and crashes while parsing it. I seem to remember that the sim didn't know about my ancient (ca. 2004) CH pedals, so it didn't have a default input profile for my "problem device".

After downloading patch 5 for MFS (the one resulting in version 1.10.7.0), MFS crashed reproducibly during launch before showing the main menu. I was told to remove all my USB game controllers and try again. MFS launched fine. I plugged in my pedals, MFS crashed. I was told to remove all my custom "input profiles" (the files where MFS stores the assignments made in Options / Controls). MFS launched fine with all game controllers connected. I opened Options / Controls. I now have only three devices there: Mouse, Keyboard, TrackIR. MFS does no longer recognize my CH Pedals, my Warthog, my custom throttle quadrant (Bodnar board), not even my Xbox Controller. I smiled. Fired up FSUIPC, started flying. Thanks, Pete & John!

I wasn't using the latest version. I find it cumbersome to follow the releases by checking the bottom of a thread. I wish the filenames would contain a qualified version number or release date. Updating to the latest version appears to have solved the issue.

The controllers I've configured using FSUIPC rarely seem to work when starting from the World Map using a custom location so that the flight starts mid-air, or when I attempt to continue my Bush Trip (Balkans, 3rd leg). I'm pretty sure that they work sometimes when starting mid-air, but I haven't figured out when or why. When trying the Bush Trip, the issue has so far been always reproducible, even when it's the first thing I try after starting the sim. I've tried other Bush Trip legs, they show the same issue (e.g. the Bush Trip in the XCub). [Edit: No, wait, my mistake, FSUIPC wasn't running when I tried other Bush Trips, because I quit it to look at its log. I even had control when starting the first leg of the Balkans trip after restarting FSUIPC, but when I tried the 3rd leg again, just as before, none of my axes, buttons, switches and rotaries were working.] When I start a flight from the ground (via the World Map) immediately (in the same MFS session) after having the issue, the controls are working fine. There are no messages in the log that would make me think that FSUIPC is aware of a problem. The aircraft in the Balkans trip is the C172 G1000, I completed dozens of flights with it (via the World Map) without any issues. Can anyone reproduce this issue? Assuming this is a issue with the sim, how should I report that on Zendesk? "SimConnect does not work on a specific Bush Trip"? Cheers, Marc

I assume this is also the reason why I can't assign my rotary encoders to functions like "G1000 Mfd Group/Page Inc/Dec"? Does anybody know of a workaround? I'm having such a hard time using the wedding cakes on the G1000 using the mouse.

Since the release of MFS 1.9.5.0, I've not been able to reproduce this problem any longer; people stopped adding their stories to "my" thread on the MFS forums. Perhaps this one is gone for good.

Let me put my FSUIPC experience in contrast to yours: according to my SimMarket order history, I've been an FSUIPC user since 2004 (FSUIPC3). And, yet, I have no idea how to configure Aileron, Elevator and Rudder axes in a way that they behave halfway realistic, or even just predictable. I've tried handling the axes in MFS and reducing the sensitivity to a fraction of the default value (with sensitivity values of -60% down to -90%). I've tried handling the axes in FSUIPC with extreme response curves and by manipulating the min/max values in the ini file, sacrificing the full range of control surface motion for more precise control. Nothing I tried resulted in the kind of control I get in P3D. I suspect it's a quirk of MFS. I'm using "quirk" because I'm just not sure if it's a bug or a feature. Perhaps the controller code in MFS is super smart and optimized to make any aircraft flyable with an Xbox controller with all the assists turned on. Perhaps it has some kind of "power steering" logic. I don't know what's up with it, but, to me, it just feels wrong. It so frustrating that every subtle elevator or rudder movement seems wildly exaggerated when I'm preparing to touch down (ie. when the aircraft is as slow as can be), while my very limited real-world flying experience is that the aircraft needs more, not less, controller movement in slow flight (not sure if it's even a controller issue at this point, could as well be a flight dynamics issue; maybe someone with more IRL experience can chime in here). And don't get me started on the behaviour of the rudder in the moment of touchdown with one wheel in a crab. So, yeah, if anybody has a setup that results in something that feels halfway realistic, I'd be happy to try it out. (I'm currently flying with a Warthog, mostly using the default C172/G1000.)

Yeah, the bug wasn't gone after all, I guess my test flights were just too short. MFS crashed earlier today, I provided the "user-mode dump" (aka application crash dump) to Asobo via Zendesk. Thanks to Visual Studio, I learned that the issue is a classical segmentation fault: Unhandled exception at 0x00007FF62D477B43 (FlightSimulator.exe) in FlightSimulator.exe.3440.dmp: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF. And this is what the stack looks like (not very informative, since Visual Studio is missing the debugging information for the executable), but, as I understand it, it definitely points to a problem in the MFS code (instead of a problem in the Visual C++ runtime dll):

Correction: ucrtbase.dll is indeed part of the Visual C++ runtime, and the reference to Visual Studio makes sense in the context of the download page for the runtime packages (the latest runtimes are labeled "Visual Studio 2015, 2017 and 2019" on that page). So they basically just told me to update the Visual C++ runtime – I'm not sure why I wouldn't have had the latest version already. I'll keep the crash dumps enabled for a while, so I can provide better information to Asobo if the runtime update didn't get rid of the crash after all.

In response to my Zendesk ticket, I just got the following advice from Asobo support: I did not have Visual C++ or Visual Studio installed when the crashes started to happen or when I reported the bug on Zendesk and here in the forums. My PC dedicated to simming and gaming is just a year old and never had any IDE installed. Unless it's a component of the "Visual C++ Runtime" packages which are part of many application installers, I have no idea where the ucrtbase.dll on my system came from. If it is in fact a part of the Runtime package, I wonder why Asobo didn't tell me to update the Runtime only, instead of specifically mentioning Visual Studio. But incidentally, I did in fact install Visual Studio 2019 recently, after reading this very informative post on the MFS forums about crash dumps (and how to write them and read them), but before I got the response from Asobo: https://forums.flightsimulator.com/t/crash-to-desktop-known-issue-what-happens-from-now-on/297218/40 So, by pure chance, I had already done what Asobo recommended. And here's the funny part: it might have worked. Since setting my system up to write crash dumps and installing Visual Studio to be able to have a look at those dumps, I've been unable to reproduce the "SimConnect crash". (btw, I found another MFS user with exactly the same issue on the MFS forums. In his case, the SimConnect applications are Little Navmap, Navigraph Charts and FSUIPC. So I'm really not hallucinating that there is a problem. 😄)

I filed a bug on Zendesk, and included a couple of examples of the crash information produced by the "Reliability History" tool. I seem to remember there's a way to get more detailed crash reports from Windows (than with Event Viewer or Reliability History) with the help of a tool that doesn't come with Windows (not sure if by Microsoft or by a 3rd party), but my Google-fu fails me. Here's a short quantitative analysis of the SimConnect log of a flight ending in a MFS CTD: Lines in file: 1498660 Clients: > 3.99297 [320, 1]Open: Version=0x00000004 Name="Little Navconnect" > 17.74603 [381, 1]Open: Version=0x00000005 Name="FSUIPC7" > 17.79976 [382, 1]Open: Version=0x00000005 Name="FSUIPC7_AItraffic" > 1041.62965 [63, 1]Open: Version=0x00000003 Name="FS Economy" Usage by client: 63: 6973 # FS Economy 320: 2485 # Little Navmap's Little Navconnect 381: 1471255 # FSUIPC7 382: 7091 # FSUIPC7_AItraffic Usage by event/class/command/object/whatever: Open: 4 AddToDataDefinition: 1360 SubscribeToSystemEvent: 28 RequestDataOnSimObjectType: 2550 MapClientEventToSimEvent: 1107 SetInputGroupState: 1 ObjectDataByType: 2705 RequestSystemState: 1782 ObjectAddRemove: 837 RequestFacilitiesList: 330 Facilities Request: 10230 Event: 351474 EventFrame: 251861 ObjectData: 871878 Exceptions: < 36.43413 [382] >>>>> EXCEPTION=3, SendID=33, Index=-1 <<<<< < 332.20962 [382] >>>>> EXCEPTION=3, SendID=37, Index=-1 <<<<< < 334.78455 [382] >>>>> EXCEPTION=3, SendID=40, Index=-1 <<<<< < 1800.05275 [382] >>>>> EXCEPTION=3, SendID=792, Index=-1 <<<<< < 3765.15386 [382] >>>>> EXCEPTION=3, SendID=1903, Index=-1 <<<<< Last lines of log: < 4545.17444 [381] ObjectData: RequestID=14 DefineID=14 dwSize=508 < 4545.17448 [381] ObjectData: RequestID=24 DefineID=24 dwSize=96 < 4545.17459 [381] EventFrame: 2 58.013054 < 4545.17475 [381] ObjectData: RequestID=10 DefineID=10 dwSize=1096 < 4545.17476 [381] ObjectData: RequestID=9 DefineID=9 dwSize=48 < 4545.19208 [381] ObjectData: RequestID=14 DefineID=14 dwSize=460 < 4545.19211 [381] ObjectData: RequestID=24 DefineID=24 dwSize=96 < 4545.19223 [381] EventFrame: 2 55.304535 < 4545.19239 [381] ObjectData: RequestID=10 DefineID=10 dwSize=856 < 4545.19241 [381] ObjectData: RequestID=9 DefineID=9 dwSize=48 Relevant lines of FSUIPC log: ********* FSUIPC7, Version 7.0.0-Beta (6th October 2020) by John & Pete Dowson ********* […] 104953 Running in "KittyHawk", Version: 11.0.282174.999 (SimConnect: 11.0.62651.3) […] 464640 -------------------- Starting everything now ---------------------- [NO log entries deleted here, there's really no output between 464640 and 4636390] 4636390 Failed on SimConnect_CallDispatch for Message, return = 0xC000014B 4636390 Failed on SimConnect_CallDispatch for Traffic Message, return = 0xC000014B 4639312 MSFS no longer running - trying to find... 4639312 === Calling SimConnect_Close ... I can't see anything special perusing the end of the SimConnect log, everything that's happening in the log in the last few minutes before the crash is also happening during the whole duration of the flight. Still, after a couple more attempts to do extended flights with all three SimConnect clients (FSE, LNM, FSUIPC) active, the pattern remains the same: MFS crashes when FSUIPC is running, even with a freshly generated and unmodified FSUIPC7.ini (one exception: I disabled "Exit with FS"). To me, this seems to be more evidence that the SimConnect code in MFS is causing these crashes on my system, and looking at the SimConnect usage of my three SimConnect clients, I feel it makes sense that a client causing the sim to do more work would be more likely to… erm… make the SimConnect problems visible (almost 1.5 mio SimConnect "events" are related to FSUIPC, compared to fewer than 10000 "events" for FSE and LNM combined). I will continue to test after each new MFS patch, but, for now, I feel I've done enough testing and I'll return to flying without FSUIPC and without access to half of my buttons and knobs. 😭 Also, there's a typo in the menu: "Miscelleneous" ("Miscellaneous") Cheers, Marc

Is that the "Events" category from the FSUIPC Log menu? Thanks for the advice on how to keep my controller settings with a fresh ini. I'll do some more testing and will report the issue to Asobo.

Because it exclusively happens while FSUIPC is running and connected. I've repeated two separate two hour flights (different routes, different aircraft) three times each under the same conditions while running FSUIPC and once each without. For both flights, MFS crashed in roughly the same stage of the flight after covering about the same distance when FSUIPC was active, while I could complete the flight without issues when FSUIPC was not running. This might be anecdotal evidence to you, but it was conclusive enough for me to bring it up here. I did not add any community mods to my sim, and I'm not using any add-ons except TrackIR, the FS Economy client, Little Navmap and FSUIPC. I have used the FS Economy client and Little Navmap continuously since shortly after release of MFS without any issues and, before FSUIPC entered the equation, in the six weeks since the launch of MFS I have experienced a single crash in about 300 hrs of "time spent in game" (according to Steam), and that crash was caused by an "imported" aircraft on an official community group flight and affected many other players (after that crash, I switched multiplayer models to "generic", I'd rather see everybody flying in 172's than risk a crash), so I feel my system is stable enough to run MFS without issues. I only started using FSUIPC a few days ago. At first I did mostly short flights (to test controller setup etc.) and saw no issues. Only in the past two days, when I tried longer flights with FSUIPC, MFS started crashing regularly, as described. I actually pointed out explicitly that I don't believe FSUIPC is the culprit in this scenario. And that I believe that FSUIPC might be triggering a resource exhaustion in the SimConnect code. If that were the case, of course the INI settings would make a difference, because different settings lead to different usage of the SimConnect interface. Also, I stated in my original post that FSUIPC was not affected by the crash. While I understand your frustration about people coming in here complaining about their MFS crashes, there seems to be no way forward for me at this point, so I'll just stop using FSUIPC for the time being, hoping that the issue will affect enough other users that it will at some point be taken care of. Thanks.

Hi, I'm running FSUIPC7 with a configuration inherited from previous FSUIPC versions for P3D, because it knows all about my plethora of HID devices. Sadly, I found that whenever FSUIPC is running, MFS will crash after a certain time. I'm saying it's reproducible, because when I redo the same flight with the same aircraft and the same route, the crash will very likely happen after covering roughly the same distance. When MFS crashes, it just CTDs without hanging first (there are no Windows "not responding" or other dialogs). Most of the time, the Event Viewer assigns the blame ("faulting module") to "FlightSimulator.exe" itself, sometimes to "C:\WINDOWS\System32\ucrtbase.dll". If I had to guess: some form of SimConnect-related resource exhaustion (read: leak) in MFS? FSUIPC just states that "MSFS no longer running" and is otherwise unaffected. My FSUIPC version is a few weeks old. Since FSUIPC only talks to MFS using SimConnect, and no SimConnect application should ever be able to crash the sim it talks to, I didn't bother to retest this with the latest FSUIPC release. I will update before trying again. How would I go about isolating the underlying issue of the crash? If I start over with a fresh .ini, can I transfer my controller setup to the new file instead of redoing the whole configuration, calibrations and assignments in FSUIPC7? I've attached ini and log of the last flight. Thanks Marc PS: I also came across an issue with large log files being written for random lua scripts after enabling and disabling separate LUA logs while debugging an issue with one of my scripts, but I'll have to retest that with the latest FSUIPC version. The MFS crashes are happening whether my lua scripts are active or not (I disable them by changing the file extensions and restarting FSUIPC). FSUIPC7.ini FSUIPC7_prev.log

Much obliged! My issue was indeed caused by a missing wxstationlist.bin file in the program folder, which caused the wxstationlist.bin in the Roaming folder to not be created at all. Not sure what happened, most likely pilot error. Thanks again, Marc PS: Of course now, after the issue is fixed, I notice that this is actually answered in the topmost issue in the FAQ section. Shame on me. m(