Hi guys! I'm having those problems on my ROG Ally and I spent several days measuring it and trying to find workarounds with AI.
I basically have two problems: after waking the device (the power button) the virtual controller doesn't work anymore (the controller gets grayed out in reWASD and it disappears from joy.cpl). Clearing reWASD data on settings does solve it, but it happens again after putting the device to sleep again (which happens all the time because it's a handheld). The second problem are those "ghost controllers" that keep appearing as I use the device.
My current workaround is to just not use the virtual controller, works but quite limiting when it comes to remap.
The rest of this post was written by Claude (Anthropic's AI assistant), which I have been using to help me debug this. All the measurements come from my own ROG Ally and my own desktop PC, captured with diagnostic scripts we built together over several days; the AI's part was designing the tests, reading the data and organising it into something readable. I am posting it as-is because it is clearer than what I would write by hand, and I did not want to pass it off as my own writing.
Thanks a lot for reading all of this, and thanks for the tool. Everything above happens on one specific machine; on my desktop reWASD has been rock solid.
--- Technical report below, written by an AI assistant ---
Setup
Device: ASUS ROG Ally (built-in gamepad)
OS: Windows 11 Home, build 26200
reWASD: 9.5.0.11346
Control machine: desktop PC, same reWASD version, Xbox One S over Bluetooth
There are two problems below. They are related — the second is the mechanism
behind the first — but they are described separately because the first one is
what makes the device unusable.
================================================== ==========
PROBLEM 1 — after resume, the virtual controller never comes back
What happens
1. Clear data in reWASD. The virtual controller works: joy.cpl lists
"Controller (XBOX 360 For Windows)", Steam Big Picture works, games work.
2. Press the power button, then wake the device up.
3. The controllers in the reWASD UI are greyed out, the virtual controller is
gone, and joy.cpl is now completely empty.
Step 3 is the worst possible combination: the physical pad is still hidden
(the profile has "convert to virtual" on), but the virtual one is not there. So
there is no usable device at all — not even Start responds.
For comparison, the same reWASD version on the desktop behaves exactly as
expected. Reading joy.cpl in four states:
Desktop, virtual OFF — lists the physical Bluetooth pad
Desktop, virtual ON — lists "Controller (XBOX 360 For Windows)"
ROG Ally, virtual OFF — lists "Controller (XBOX 360 For Windows)"
ROG Ally, virtual ON — lists nothing
So hiding the physical device works on both machines. The only thing that fails
on the Ally is the virtual one showing up.
The virtual bus driver is not the problem
ROOT\SYSTEM\0002 (FriendlyName "System Driver", provider "R Team", kernel
service wjl19drv 3.48.0.0) reports status = OK in every single round, before and
after the failure. It does not die — it just ends up with no child device.
What actually happens: the pad re-enumerates
This is the part that seems to matter. Comparing full PnP snapshots taken before
and after one power cycle:
The pad itself, USB\VID_045E&PID_028E\1DD5F3D — present before, present after,
same parent (USB\ROOT_HUB30\...). Unchanged.
Its child interface — &IG_02 before the cycle, &IG_00 after it.
The device never changes. The interface does. That is the opposite
of what we assumed for weeks: looking for the pad disappearing from PnP finds
nothing, because it never disappears.
reWASD then registers that re-enumeration as a new ContainerId in
GamepadCollection.json, instead of recognising it as the same pad it already
knows.
We could not stop the re-enumeration — everything Windows offers was tried
USB selective suspend (power plan, AC and DC) set to 0 / 0 — still re-enumerated
EnhancedPowerManagementEnabled (device) set to 0 — still re-enumerated
SelectiveSuspendEnabled (device) set to 0 — still re-enumerated
AllowIdleIrpInD3 (device) set to 0 — still re-enumerated
Two full power cycles with all four zeroed, both confirmed by Kernel-Power
events 506 (entering Modern Standby) and 507 (leaving it). Both
re-enumerated anyway.
The Ally is a Modern Standby-only machine — powercfg /a shows S3 does not even
exist there. So re-enumerating on resume looks like normal, unavoidable
behaviour of this hardware, and there does not appear to be anything
configurable on the user's side that prevents it.
And reWASD is not the one causing the re-enumeration
We checked whether reWASD itself was triggering it by hiding and unhiding the
device. It is not. With the jlserv service stopped, a full power cycle
still re-enumerated the interface — and zero new containers appeared;
GamepadCollection.json was not touched at all.
So: the system re-enumerates, and reWASD turns each re-enumeration into a new
identity when it is running.
The request
Could reWASD recognise a re-enumerated pad as the same device and rebind to it,
instead of registering a new ContainerId? On a handheld, sleeping is not an edge
case — it is the normal way the device is used, many times a day. Right now
every single sleep costs a full recovery.
================================================== ==========
PROBLEM 2 — duplicate / ghost controllers pile up
This is the mechanism behind the above, and it is visible in the UI as several
greyed-out little controllers for one physical pad.
Duplicates alone are harmless — containers are what break it
This distinction took a while to find, and it is probably the most useful thing
in this post. Four rounds on the Ally:
Right after Clear data — 10 entries, 1 distinct ContainerId — works
After one sleep — 13 entries, 2 distinct ContainerIds — dead
After restarting jlserv — 17 entries, 4 distinct ContainerIds — works for
about one second, then stops
After recovery — 2 entries, 1 distinct ContainerId — works
Ten duplicated entries inside one container worked perfectly — they share
both ContainerId and Ids, so they are the same device recorded several times.
What breaks things is a new identity appearing. With 2 or more
containers, reWASD appears to apply the profile to all of them, and the phantoms
undo what the good one just did. On screen that is exactly the symptom:
Big Picture works for one second and then stops.
Worth noting: in every round, all entries carry the same Ids value
(314691223017054013) — so the information needed to tell they are the same
physical pad does appear to be in the file already.
Also, in case it helps narrow down what the UI reflects:
IsInitializedController is True in all 13 entries, both before and after the
failure — so whatever the grey dot means, it is not that field.
Three things that do not help, in case they save someone time
Restarting jlserv makes it worse. It went from 2 to 4 containers and the
virtual controller still did not come back. It does light one of the icons up
again, which is misleading.
wjl19drv cannot be restarted — it returns error 1052 ("the requested
control is not valid for this service"), which makes sense for a BOOT_START
driver with no stop handler.
Killing reWASD to recover is a bad idea — it forces the license to be
selected again afterwards and throws several errors along the way. Closing it
properly from the tray first works fine.
The only recovery we found
Close reWASD from the tray, stop jlserv, move
C:\ProgramData\Disc-Soft\reWASD\GamepadCollection.json out of the way, start the
service, reopen. That is effectively "Clear data", and it does restore
everything — until the next sleep.
If there were a supported way to reset just the gamepad collection without
closing the app and re-selecting the license, that alone would make the current
situation much more livable while the root cause is looked at.
================================================== ==========
The current workaround, for anyone hitting the same thing
We stopped depending on the virtual controller on the handheld: instead of
"convert to virtual", the physical controller is kept visible. It survives the
re-enumeration precisely because nothing about it depends on the virtual device
being recreated.
It does have a cost worth knowing about: any macro with a gamepad output
still instantiates the virtual controller, and with the physical one also
visible the game then sees two devices and picks one — and different games pick
differently. In this library that is 119 gamepad outputs across 22 profiles,
which are being converted to keyboard keys one at a time.
Two small pieces of feedback related to that:
Turning the virtual controller off in the reWASD UI deletes every mapping
with a gamepad output, silently. We measured it twice — one profile lost 3
mappings, another lost 2. A confirmation naming how many mappings would be
removed would have saved a couple of restores from backup.
The "Xbox 360 virtual" toggle staying lit after the physical controller is kept
was confusing at first, though it makes sense now: it answers a different
question ("does a virtual device exist?") than the one being asked ("is my
physical pad hidden?").
================================================== ==========
What can be provided
There are PowerShell scripts here that snapshot the full state — PnP tree with
parents and interfaces, GamepadCollection.json, container IDs, services, device
and power-plan settings, Kernel-Power events — and diff two runs, so a clean
before/after can be captured around any test you would like. The
GamepadCollection.json files from each of the rounds in the table above were
kept as well, and reWASD logs can be pulled if they would help.
Just say what would be most useful and it will be run.
I basically have two problems: after waking the device (the power button) the virtual controller doesn't work anymore (the controller gets grayed out in reWASD and it disappears from joy.cpl). Clearing reWASD data on settings does solve it, but it happens again after putting the device to sleep again (which happens all the time because it's a handheld). The second problem are those "ghost controllers" that keep appearing as I use the device.
My current workaround is to just not use the virtual controller, works but quite limiting when it comes to remap.
The rest of this post was written by Claude (Anthropic's AI assistant), which I have been using to help me debug this. All the measurements come from my own ROG Ally and my own desktop PC, captured with diagnostic scripts we built together over several days; the AI's part was designing the tests, reading the data and organising it into something readable. I am posting it as-is because it is clearer than what I would write by hand, and I did not want to pass it off as my own writing.
Thanks a lot for reading all of this, and thanks for the tool. Everything above happens on one specific machine; on my desktop reWASD has been rock solid.
--- Technical report below, written by an AI assistant ---
Setup
Device: ASUS ROG Ally (built-in gamepad)
OS: Windows 11 Home, build 26200
reWASD: 9.5.0.11346
Control machine: desktop PC, same reWASD version, Xbox One S over Bluetooth
There are two problems below. They are related — the second is the mechanism
behind the first — but they are described separately because the first one is
what makes the device unusable.
================================================== ==========
PROBLEM 1 — after resume, the virtual controller never comes back
What happens
1. Clear data in reWASD. The virtual controller works: joy.cpl lists
"Controller (XBOX 360 For Windows)", Steam Big Picture works, games work.
2. Press the power button, then wake the device up.
3. The controllers in the reWASD UI are greyed out, the virtual controller is
gone, and joy.cpl is now completely empty.
Step 3 is the worst possible combination: the physical pad is still hidden
(the profile has "convert to virtual" on), but the virtual one is not there. So
there is no usable device at all — not even Start responds.
For comparison, the same reWASD version on the desktop behaves exactly as
expected. Reading joy.cpl in four states:
Desktop, virtual OFF — lists the physical Bluetooth pad
Desktop, virtual ON — lists "Controller (XBOX 360 For Windows)"
ROG Ally, virtual OFF — lists "Controller (XBOX 360 For Windows)"
ROG Ally, virtual ON — lists nothing
So hiding the physical device works on both machines. The only thing that fails
on the Ally is the virtual one showing up.
The virtual bus driver is not the problem
ROOT\SYSTEM\0002 (FriendlyName "System Driver", provider "R Team", kernel
service wjl19drv 3.48.0.0) reports status = OK in every single round, before and
after the failure. It does not die — it just ends up with no child device.
What actually happens: the pad re-enumerates
This is the part that seems to matter. Comparing full PnP snapshots taken before
and after one power cycle:
The pad itself, USB\VID_045E&PID_028E\1DD5F3D — present before, present after,
same parent (USB\ROOT_HUB30\...). Unchanged.
Its child interface — &IG_02 before the cycle, &IG_00 after it.
The device never changes. The interface does. That is the opposite
of what we assumed for weeks: looking for the pad disappearing from PnP finds
nothing, because it never disappears.
reWASD then registers that re-enumeration as a new ContainerId in
GamepadCollection.json, instead of recognising it as the same pad it already
knows.
We could not stop the re-enumeration — everything Windows offers was tried
USB selective suspend (power plan, AC and DC) set to 0 / 0 — still re-enumerated
EnhancedPowerManagementEnabled (device) set to 0 — still re-enumerated
SelectiveSuspendEnabled (device) set to 0 — still re-enumerated
AllowIdleIrpInD3 (device) set to 0 — still re-enumerated
Two full power cycles with all four zeroed, both confirmed by Kernel-Power
events 506 (entering Modern Standby) and 507 (leaving it). Both
re-enumerated anyway.
The Ally is a Modern Standby-only machine — powercfg /a shows S3 does not even
exist there. So re-enumerating on resume looks like normal, unavoidable
behaviour of this hardware, and there does not appear to be anything
configurable on the user's side that prevents it.
And reWASD is not the one causing the re-enumeration
We checked whether reWASD itself was triggering it by hiding and unhiding the
device. It is not. With the jlserv service stopped, a full power cycle
still re-enumerated the interface — and zero new containers appeared;
GamepadCollection.json was not touched at all.
So: the system re-enumerates, and reWASD turns each re-enumeration into a new
identity when it is running.
The request
Could reWASD recognise a re-enumerated pad as the same device and rebind to it,
instead of registering a new ContainerId? On a handheld, sleeping is not an edge
case — it is the normal way the device is used, many times a day. Right now
every single sleep costs a full recovery.
================================================== ==========
PROBLEM 2 — duplicate / ghost controllers pile up
This is the mechanism behind the above, and it is visible in the UI as several
greyed-out little controllers for one physical pad.
Duplicates alone are harmless — containers are what break it
This distinction took a while to find, and it is probably the most useful thing
in this post. Four rounds on the Ally:
Right after Clear data — 10 entries, 1 distinct ContainerId — works
After one sleep — 13 entries, 2 distinct ContainerIds — dead
After restarting jlserv — 17 entries, 4 distinct ContainerIds — works for
about one second, then stops
After recovery — 2 entries, 1 distinct ContainerId — works
Ten duplicated entries inside one container worked perfectly — they share
both ContainerId and Ids, so they are the same device recorded several times.
What breaks things is a new identity appearing. With 2 or more
containers, reWASD appears to apply the profile to all of them, and the phantoms
undo what the good one just did. On screen that is exactly the symptom:
Big Picture works for one second and then stops.
Worth noting: in every round, all entries carry the same Ids value
(314691223017054013) — so the information needed to tell they are the same
physical pad does appear to be in the file already.
Also, in case it helps narrow down what the UI reflects:
IsInitializedController is True in all 13 entries, both before and after the
failure — so whatever the grey dot means, it is not that field.
Three things that do not help, in case they save someone time
Restarting jlserv makes it worse. It went from 2 to 4 containers and the
virtual controller still did not come back. It does light one of the icons up
again, which is misleading.
wjl19drv cannot be restarted — it returns error 1052 ("the requested
control is not valid for this service"), which makes sense for a BOOT_START
driver with no stop handler.
Killing reWASD to recover is a bad idea — it forces the license to be
selected again afterwards and throws several errors along the way. Closing it
properly from the tray first works fine.
The only recovery we found
Close reWASD from the tray, stop jlserv, move
C:\ProgramData\Disc-Soft\reWASD\GamepadCollection.json out of the way, start the
service, reopen. That is effectively "Clear data", and it does restore
everything — until the next sleep.
If there were a supported way to reset just the gamepad collection without
closing the app and re-selecting the license, that alone would make the current
situation much more livable while the root cause is looked at.
================================================== ==========
The current workaround, for anyone hitting the same thing
We stopped depending on the virtual controller on the handheld: instead of
"convert to virtual", the physical controller is kept visible. It survives the
re-enumeration precisely because nothing about it depends on the virtual device
being recreated.
It does have a cost worth knowing about: any macro with a gamepad output
still instantiates the virtual controller, and with the physical one also
visible the game then sees two devices and picks one — and different games pick
differently. In this library that is 119 gamepad outputs across 22 profiles,
which are being converted to keyboard keys one at a time.
Two small pieces of feedback related to that:
Turning the virtual controller off in the reWASD UI deletes every mapping
with a gamepad output, silently. We measured it twice — one profile lost 3
mappings, another lost 2. A confirmation naming how many mappings would be
removed would have saved a couple of restores from backup.
The "Xbox 360 virtual" toggle staying lit after the physical controller is kept
was confusing at first, though it makes sense now: it answers a different
question ("does a virtual device exist?") than the one being asked ("is my
physical pad hidden?").
================================================== ==========
What can be provided
There are PowerShell scripts here that snapshot the full state — PnP tree with
parents and interfaces, GamepadCollection.json, container IDs, services, device
and power-plan settings, Kernel-Power events — and diff two runs, so a clean
before/after can be captured around any test you would like. The
GamepadCollection.json files from each of the rounds in the table above were
kept as well, and reWASD logs can be pulled if they would help.
Just say what would be most useful and it will be run.
Comment