Godot Version
At least versions (of mono win64):
4.2.2
4.4
4.5.1
(I doubt C# has anything to do with this stall as it seems to be related to input device gathering by the godot engine)
Question
This is half a question and half a post documenting some poor behaviour between Godot and a HID device driver for a Huion tablet that I have. This may be very rare behaviour specific to the history of my computer and what software it is running, but it may help someone else. After documenting the behaviour, the question will be general advice for resolving such an odd conflict that seems to come from nowhere.
Behaviour
Antecedents:
- Huion Inspiroy Q620M drawing tablet both bluetooth connected and connected by charging cable. If it is not connected by the charging cable, the behaviour does not occur.
- Any godot program (I have tested 3,including the editor) running.
- Sleep the computer and wake it.
Consequent:
- Godot stalls (wait chain for input device) for long periods of time. If patient and a UI element has attempted to be interacted with, then the program will begin responding and running as normal. As far as I can tell, the wait-chain will not happen again until the next sleep and wake.
- Additionally, once this has happened, starting a godot program also takes a long time because of the same wait chain attempting to resolve the input device.
- Failure to wait with the window open and focused will result in no progress being made to resolve the wait chain.
Steps taken to Diagnose:
- Wake computer from sleep while running a godot program
- Open Resource Monitor (RESMON) > CPU > right click affected godot program (red highlighted) > Analyze Wait Chain
- For me this popped up info about two threads related to the same PID, one waiting on the other.
- Install ProcDump ProcDump - Sysinternals | Microsoft Learn
- Install Some form of WinDbg to open the resulting .dmp file
- Find the PID using the Resource Monitor
- Open a terminal (elevated to admin I assume) and navigate to the ProcDump program folder
- Repeat step 0.
- Execute the following command with replaced: .\procdump.exe -mm -h
- (The .dmp file generated should be in the same folder as the procdump.exe)
- Open the file in WinDbg and use the command: !analyze -v
- Confirm a HID component/input device failure/exception in the call stack or scroll down the analysis output window and find the Module_Name: hid. (I am no Windows OS guru, so I cannot give more detailed instructions about WinDbg as this is the first time I have had to use it).
Resolution:
Unclear to me so far as I have not yet spent time fixing this. I suspect I will simply have to uninstall and reinstall the drivers for the tablet. Interesting enough, I have had this tablet plugged in like this for months prior without issue. Notable features about my computer is that this tablet’s driver was originally installed on windows 10 and then migrated to windows 11, though this had also been done for several months. The second thing I think may have had an impact is the purchase of a new XBOX One controller to replace and older controller that I had. It seemed to have trouble with steam properly recognizing it and causing input stall / interrupts / disconnections for games, seemingly at random. This controller does not need to be present or plugged in for the aforementioned issue to occur, but I did have to update Microsoft Xbox drivers / software at this time and I do not remember if the issues were occurring before or after this as I have been busy with manual labour.