Site Login

This Months Donations

of $500.00 goal
Server, CDN, Network, Licensing
Development Budget
Developers Beer Fund
Frederick J Hogsett
Karl Scahill
Ryan Caron
Number of donations
Highest donation
Average donation

Though the possibility of this break being in the release version of the AU patch has existed for some time now, as a developer with limited resources, I cannot take odd behavior in preview, insider, early builds seriously. With the limited resources (time) I have, theorizing and debugging the odd behaviours of a essentially "hackish" program within an operating system that is on its best days unpredictable is infeasible.

There have been reports for weeks now from insider users claiming that exclusive mode breaks on the insider build, but my response has alwayse been that I can not worry about the instabilities in inside builds because there could be any number of things causing it and 99% of them are on Microsoft's side and unavoidable anyway. I cite the same issues people had when Windows 10 first came out. Exclusive mode was broken for everybody and the only way around it was to task kill Windows Explorer. This was something I couldn't avoid but it tuns out Microsoft was aware of the issue either of their own accord or because enough of us raised a stink, and resolved the issue shortly after in a service patch. The issue was not IM's fault and the solution had nothing to do with IM.

A similiar issue arose in the AU update just released where a still undetermined Windows process is going around and opening every HID device it can enumerate, and thus getting in the way of IM's ability to open the device exclusively. This isn't something that we can modify IM to avoid as the conflict takes place within kernel32.dll. We did the only thing we can do, grab the pitchforks and march on Microsoft. I put the word out in every form in my desposal to goto a issue I created on Microsofts forum and vote for it to raise awareness ( So far with 400+ users backing it it is one of the fastest growing threads on Microsoft now. That isn't to say it is going to change anything for us, but it is the only tool I have at my disposal.

The pInvoke that I use to access HID devices in the Windows Kernel allows for a dwShareMode parameter to determine if windows will open it exclusively. Well this parameter, while still present, is completely worthless in the new Windows update since Windows itself is opening every single HID device it can find, thus making attempts to access exclusively by definition impossible. Despite speculation by some I do not believe this to be an attempt by Microsoft to target non 360/One controllers, but instead a oversight mixed with some sloppy code. Though I'm not sure that is any better. 

Luckly thanks to a forum user ZAMHome, a workaround has been found Though this does not "fix" the underlying issue, it does get users back to their games if they were forced into the AU update.

Log in to comment