Upon Loading ED after a reboot you get an error about not being able to find a device, no controllers, and the Bindings folder has a new file called BindingLoadingErrors.log

[matt232h]

Firstly thanks for providing this, its much appreciated I would have been lost having only just bought the controllers.

Offering this as a suggested workaround/fix for this issue. At most I'd suggest this is an addition to the README.md or FAQ, or happy to leave this as a closed issue just as a reference if anyone comes looking

Using the Full map with a few additions to the mappings for the extra stuff in ED Horizons. Also followed the suggestions in #10 for a full + to - throttle.

This suggested solution/workaround to avoid the issue is kind of similar to what is mentioned in Issue #11 with enough differences that seem enough to have its own ticket.

Issue Description

Upon Loading ED after a reboot you get an error about not being able to find a device, no controllers, and the Bindings folder has a new file called BindingLoadingErrors.log

Within the %LOCALAPPDATA%\Frontier Developments\Elite Dangerous\Options\Bindings\BindingLoadingErrors.log it lists a number of lines stating "Failed to find GUID for device: 068EC010" (or something similar as the hardware ID will change depending on controller your setup in CH Control Manager but a hardware ID of 068EC010 should be right for this setup). The StartPreset.start file has also defaulted back to "KeyboardMouseOnly" rather than "CH Products Cmdr Davis" (this needs to be corrected) and your graphics settings are reset as well.

Suggested way to avoid this occurring

I've listed some steps here on my process to avoid the issue. Similar to what was mentioned http://www.ch-hangar.com/forum/index.php?/topic/8029-elite-dangerous-has-to-be-re-configured-after-every-reboot/&tab=comments#comment-54685

Essentially I'm using the below PowerShell command to verify the right devices are present before opening the game. The below is a listing of my "Healthy and good to go" setup as an example. The key line of the output is the one with "CH Control Manager Device 1" which matches to the virtual device of all controllers combined.

Get-PnpDevice -PresentOnly -Class "CHProducts" | Select Status,FriendlyName,HardwareID | ft -autosize

Status FriendlyName                   HardwareID
------ ------------                   ----------
OK     CH Pro Throttle USB Hardware   {USB\VID_068E&PID_00F1&REV_0000, USB\VID_068E&PID_00F1}
OK     CH Control Manager Device 1    {CHProducts\VID_068E&PID_C010}
OK     CH Fighterstick USB Hardware   {USB\VID_068E&PID_00F3&REV_0000, USB\VID_068E&PID_00F3}
OK     CH Control Manager Root Device {CHProducts\VID_068E&PID_C020}
OK     CH Pro Pedals USB Hardware     {USB\VID_068E&PID_00F2&REV_0000, USB\VID_068E&PID_00F2}
OK     CH Control Manager Aux1 Device {CHProducts\VID_068E&PID_C000}
OK     CH Control Manager Aux2 Device {CHProducts\VID_068E&PID_C001}```

[domdavis]

Thanks for this. Although I've never had this issue (yet - famous last words 😃 ) I'm happy to create a trouble shooting section and add it there since it may help others.

I've actually got a new version of the map which I'm using and keep meaning to get up on here, and will likely include this information as part of the update. I'll leave the issue open until that's done (not least to goad me into doing it sooner rather than later).

[domdavis]

I've just pushed a complete rebuild of the map. I suspect the issue you're seeing is that if the devices aren't loaded ED just defaults back to a working map. I've also moved to simply using the custom name that ED uses (currently Custom.3.0.binds). Hopefully this will help mitigate the problem.

[alecvance]

First of all thanks for sharing this amazing resource! It's greatly enhanced my enjoyment of E:D these past 2+ years.

I never had this issue before — until recently with the latest version of ED. I saw that a lot of other people were having or have had this issue (on the Frontier and other forums), and had suggestions — I tried everything to no avail. I then found this thread and saw that you had a new rebuild of the map and binds. I loaded those into Elite and I was back in business! Until the next computer restart, that is, sadly now I'm back to square one, and reinstalling your binds did not solve this.

Running the command that @matt232h suggests above shows that the Control Manager devices are correctly registered, but the BindingLoadingErrors.log still lists a number of lines stating "Failed to find GUID for device: 068EC010" for Custom.binds.

Any help here would be appreciated.

[domdavis]

Ok, so 068EC010 is in the bindings file so what I’m assuming here is that my HOTAS have a unique ID (either given to them by Windows, or by the control manager). Elite is then using that ID to identify the device. For now the fix would be to open the bindings file and search and replace that ID with the ID for your device. I believe there’s instructions on how to find that in this thread but I’m on my phone currently so can’t check. Reopening this to investigate further but it’s likely to be a couple of days before I can.

[domdavis]

One really hacktastic way to find your ID would be to download the joystick map in the control software, start ED, create your own custom config from a blank template, map an axis to something, exit, open the file, find the ID, replace 068EC010 in my mapping file with that ID, overwrite your temporary mapping file with my one. It’s a faff and not pretty, but may get you going until I can sort a better solution.

[alecvance]

Thanks for that, I'll try it. For some reason the Fighterstick is being recorded as "068EC0F3" and the Pro Throttle as "CHProThrottle2" in the new .binds file it writes. Odd that one gets a name and the other gets a number. The number does match the hardware ID of the Fighterstick, as shown in the output that @matt232h posted, which matches my result. It seems that Elite can see the individual devices but not the Control Manager, so I am thinking this is a problem with the ancient Control Manager losing compatibility with updated Oculus, Windows system, or Elite software.

[matt232h]

Seems the CH-hanger website has shut down so there is some missing context now.

This is my process to avoid the problem after any and every restart of the computer (nothing terribly revolutionary here just got to do it each time because it seems the virtual device isn't persistant across reboots):

1. Run the Get-PnpDevice -PresentOnly -Class "CHProducts" | Select Status,FriendlyName,HardwareID | ft -autosize cmdlet in a PowerShell window to establish the state
2. Open CH Manger
3. Load your profile
4. Download the profile to the device(s)
5. Run the cmdlet again to check if the combined virtual device with the noted/errored hex code from the game is present Get-PnpDevice -PresentOnly -Class "CHProducts" | Select Status,FriendlyName,HardwareID | ft -autosize
6. Listen for a device found beep and you should then see 'CH Control Manager Device 1 {CHProducts\VID_068E&PID_C010}' appear with a subsequent run of the cmdlet in the list which should correspond with the missing hex code for the device.
7. Sometimes it doesn't get programmed properly and that device doesn't appear, no beep, and CH Manager has the download button greyed out. The only option I've found is to restart the computer and start the process over again.

You can use the Get-PnpDevice cmdlet without the extra class parameter to check if that Hex code is being used elsewhere and expand your troubleshooting.

If you encounter the problem then ensure you clean up the noted changes. Setting StartPreset.start back to custom controls in Elite's binding files and even renaming the BindingLoadingErrors.log so you only get fresh errors.

[matt232h]

And again sometimes CH Manager seems to get stuck while downloading the map to the devices. Just to throw an extra spanner in the works. Reboot and try again.

try dividing and conquering by seeing if any other devices removed help things or if using other USB ports help. Or consider what has changed and focus on that to try to eliminate any connection.

[matt232h]

once you sus it out keep your own copy of a bad and good output for your setup for later reference. Handy to refer back to while you are swearing at it.

[domdavis]

I’ve tried a couple of things to try and beat this but I think ultimately it boils down to the fact that you get a unique GUID when you build the virtual stick and Elite now uses that. GenericJoystick doesn’t work in the field, nor do the CH * aliases they’ve got defined, likely because the control manager is presenting them as a virtual device.

I think the only solution is going to be to provide a tool (or detailed instructions for people who don’t want to be running random binaries) that’s will detect the correct ID for a users machine and replace it in the custom binds. The Power Shell commands above don’t work for me so will look for something that works on all windows machines.

The one thing I’m not sure of is if the GUID changes If the USB ports change. My HOTAS is permenantly connected and I’ve never had any problems after reboot. May need to go crawling under my desk to check.

[matt232h]

Yep, its a device reference issue, I don't expect any solution here. Was just trying to offer up my learnings so that it might make it easier for anyone else running into this situation. If it's not an issue for you and everyone else then that's preferable than these workarounds, so all good. No need to keep this as an open issue, feel free to close it.

To confirm its device related, I get the same thing (defaulting binding profile to Keyboard and Mouse) when I don't connect my EDTracker and it can't find that device, so not limited to CH Product devices. I have noticed in this scenario that even though you default back to keyboard and mouse binging profile, it's possible to go into settings and select the named binding profile fo the CH kit from the list and carry on, gives you a chance to modify the specific binding in-game without having to hand edit files or kind of ignore the issue (although the default loaded profile is forever changed so you need to edit the StartPreset.start file in the ED bindings settings folder to restore that). Not tried this with the CH kit, but that's more than a couple of bindings (the headlook axes with EDTracker vs almost every input from the HOTAS) so while it may work it might be impractical to change everything....still its another option.

I also ran into a situation where the CH Control Manager Root Device vanished and started being shown as an unknown device needing drivers in Window's Device Manager. The catalyst for the problem was either Nvidia driver updates, Windows Updates, Lexip Mouse installs, Pimax Pi Tool install, or random chance...not sure but I was able to recover from it eventually. The solution was to fully uninstall the CH Manager program and download the latest version of CH Control Manager (which I was already using) then install it again. That got the CH Control Manager Root Device and associated virtual devices working again and now back to validating the devices are present and reloading the map in CH Manager after each computer restart.