aurel42

As the first step, I enabled logging of Extras and Events. During one of the following flights, all my FSUIPC controls became unresponsive, while FSUIPC was running and responsive. I don't remember having something like that happen in the past year or so. And it wasn't even a long flight. The log seems to indicate that SimConnect stalled or choked. Exiting and restarting FSUIPC resolved the issue and I could continue the flight. Next step: I'll set the ini parameters you suggested. (The attached zip contains the log.) FSUIPC7-unresponsivecontrols.zip

I don't have more information than that. I attached a log and my ini. I'm using Win10 (21H1). Here's what the Windows Event Viewer has to say: Faulting application name: FSUIPC7.exe, version: 7.3.0.4, time stamp: 0x627e7a6a Faulting module name: FSUIPC7.exe, version: 7.3.0.4, time stamp: 0x627e7a6a Exception code: 0xc0000005 Fault offset: 0x00000000000e6053 Faulting process id: 0x1508 Faulting application start time: 0x01d86f8689880ebd Faulting application path: C:\FSdata\FSUIPC7\FSUIPC7.exe Faulting module path: C:\FSdata\FSUIPC7\FSUIPC7.exe Report Id: 5a89a13f-f377-4d63-a510-bccb372c2b35 Faulting package full name: Faulting package-relative application ID: How can I provide more useful information? My workaround: I just restart FSUIPC when this happens. Cheers, Marc FSUIPC7-crash.log FSUIPC7.ini

Thank you very much, John!

I spent quite a bit of time reading and re-reading the relevant parts of the Advanced User manual, searching through forums etc., but I can't seem to wrap my head around the concepts. Here's where I am: I have USB controllers with loads of switches, buttons, levers, and rotary encoders. They all work, but, so far, I can only assign them to the subset of functions available in FSUIPC, and many of those don't work as expected (no doubt Asobo is to blame for this). Here's where I would like to be: I would like to be able to assign all my controls freely to specific buttons or knobs on, for example, KAP140, GNS530, or G1000. A couple of forum posts which are about a year old discuss using MobiFlight (or, at least, MobiFlight's WASM module) together with FSUIPC as the solution, but I can't figure out whether that's still the way to go... is it? We do have FSUIPC's own WASM module now, is that meant to replace the need for the MobiFlight module or does it do something else? Is there a relationship between Lvars and SimConnect events? Do they mirror each other? Can I achieve the same results using either? Or is manipulating Lvars a backdoor, circumventing the use of the actual button in the sim, by changing the state of add-on internals, and thus not what I want to look at? Please make my brain hurt less.

The provided reg file didn't quite do the trick, but after cleaning out all the VID/PID keys from the two registry folders (and there were quite a few, most of them historical cruft), FSUIPC does not complain about duplicate GUIDs any longer. \o/ (Also, this was when the yoke stopped getting two separate GUIDs.) I reassigned my custom joystick letters and all four devices are behaving perfectly in the FSUIPC Axes and Buttons dialogs. Thank you for pointing me in the right direction!

John, thank you so much for your help. I totally realize that, by helping me with a corrupt registry, you're, once more, going above and beyond anything that could be expected. 💗 I'm familiar with regedit, just point me to the keys that need to go. 😄 FSUIPC7 - Copy (2).log FSUIPC7.ini

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.