When using ASIO, changing the playback strategy values did not have a positive effect; I used DoP and PCM, and it still resulted in BSODs with the same error message.
FYI, Steve
Hi Daniel,
Yeah, it does - good call. And it affects ASUS ROG systems, which this is.
Unfortunately, I disabled the service and there is no change - powering off the RME still results in a BSOD with the same error. I even checked it a few different ways - 2 more BSODs, the third time I went to WASAPI instead of ASIO - no crash.
Let me know if you think of something else to try. I appreciate it.
1 Like
Yay, 2004 broke other stuff too.
Oh, good. 
Just what we need.
Hi @steve_smith1,
I’ve submitted your additional details to the hardware team, but I haven’t heard back yet, trying to reproduce this behavior is still in their queue, but it has not reached the top of it just yet, once they see the new info and try reproducing again, we will let you know!
2 Likes
I had this same issue and fixed it by doing the following, not sure which worked, but now it works better than before in that you can switch off the ADI2 DAC and Roon will lose the connection (no more BSOD) but when you turn it on Roon will detect the ADI2 DAC again immediately and can play from where you left off. It wasn’t like that for me before so it’s a big improvement.
I updated the firmware on the ADI2 DAC (no change I think).
I ran a System File Check
CMD with sfc /scannow
Some errors were found and corrected.
As per https://www.thewindowsclub.com/pfn_list_corrupt-windows
Which I saw on https://community.roonlabs.com/t/roon-o … ble/110866
I then re-installed the latest RME drivers and it’s been fine since.
I think re-installing the drivers or running the SFC did the trick for me.
Hi Milo,
Thanks for the suggestions. The issue still exists after doing those items (and more).
The only thing that prevents it is using the WASAPI driver, which works for now.
According to your motherboard specifications, you have three types of USB ports: 3.1 gen 2, 3.1 gen 1, 2.0. Have you tried all these types of USB ports, do they all have the same behavior?
Hi Steve,
That’s interesting and prompted me to look again of course…
I found that (for me);
If I am actually playing music through Roon and I switch off the DAC then Roon complains that it lost control of the audio device. No BSOD. I can turn the DAC on and off and Roon will find it and lose it no problem (didn’t do that for me before, I had to restart Roon server to get the DAC back).
If however I stop the playback in Roon and then switch off the DAC I’m guaranteed a BSOD.
I would be very interested if your system does the same.
Cheers,
Milo
No, I had not until now, all three types generate the same error. I had not tried the gen 2 port.
Thanks.
Hi Milo,
You nailed that - exactly the same behavior. I never tried power on/off while playing it. And power on/off is a good workaround.
thanks,
Milo’s discovery might help the hardware team. And thanks to @wklie we know it occurs on all three types of USB ports (2.0, 3.0 gen 1 and gen 2).
-Steve
Even though you found JRiver does not cause this issue, I think your best chance of getting this solved is to follow up with RME. It looks like Windows 10 2004 broke the driver for this particular sequence of operation, which was previously working on 1909.
Hi Peter,
I posted a similar message on the RME support forum at the same time as here. After your post, I checked today and there were no new responses to my post.
However , there are now two other active threads having similar issues, one exactly the same, but with other software - Foobar2000 and Audirvana.
So I made another post today that will hopefully get things moving.
-Steve
Hi @noris,
FYI, RME reliably reproduced the issue I reported (ADI-2 DAC causing BSOD with Roon) .
-Steve
.
1 Like
Thanks for the update here! It sounds like RME is working on this issue, but if there are any updates on their end that resolve this, just let us know!
I will do.
1 Like
[Updated 8/21/20 - to reflect changes in the issue as a result of the new RME driver]
@noris,
RME released a new driver, .9722, to fix the issue and with respect to the dump file created from the BSOD, I believe it does that because the RME madiface driver is no longer the faulting module/bucked id.
While, the BSOD’s have the same error message, PFN_LIST_CORRUPT, the dump’s stack trace shows a different source for the BSOD: the kernel itself vs the RME madiface driver:
SYMBOL_NAME: nt!MiDeleteNonPagedPoolPte+1bc91d
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
FAILURE_BUCKET_ID: 0x4E_9a_nt!MiDeleteNonPagedPoolPte
VS the original, the RME driver
SYMBOL_NAME: madiface_usb_64+7d36
MODULE_NAME: madiface_usb_64
IMAGE_NAME: madiface_usb_64.sys
FAILURE_BUCKET_ID: 0x4E_9a_madiface_usb_64!unknown_function
New Behavior
- When testing, BSODs should have occurred when the DAC was not selected in Roon and was powered off. Rather than occur everytime, they seem random.
- Powering off the device should cause the device to disappear from Roon immediately. Sometimes it does and other times it stays. A BSOD occurred when I tried to playback to the “phantom” device - the dump file showed the nt kernel was the source of the fault not the RME driver as before.
[RME Info]
MC at RME provided additional information about how to possibly correct the above issue within the Roon application:
“There is a chance that ASIO hangs [when the ADI-2 DAC is switched off (into Standby, so called Surprise removal)] as it is used during that removal …the ASIO handle of the application is closed when surprise removal happens during playback or [when paused. …] The application might be able to enter [pause] mode automatically in such a case, that would prevent all issues”.
Emphasis added -> that would be the objective for Roon to achieve.
[End RME info]
Let me know if you need any more information.
Thanks,
-Steve
Hi Steve,
I saw just before so have been testing now… It’s working ok for me now so good result it seems!
Thanks for raising the issue with RME and Roon originally.
Also thanks to RME and also Roon for addressing the issue quickly.
Cheers,
Milo