I've had a couple of BSODs when using the ADI-2 DAC recently as well. I probably got an automatic update from Windows too.

Fine that it worked for you. As It was mentioned in my Memory DUMP file, the problem is caused by RME driver. but I need the new 2004 update for my work and can't roll back to previous version.

That is what I said. My crashes were page fault in non paged area.

I think its more likely that M$ introduced a problem ... see how many other issues are there with the 2004 upgrade...
In such a case rollback is the *only* solution.
I did the same for some other reasons to wait a little further until the dust settles.

Maybe 3 tips around Win10:

1. with Macrium Reflect its easy to implement a reliable Backup solution. Only the commercial solution supports two important features: a) incremental backup and b) rapid delta restore (when restoring only changed blocks will be written to SSD to speed-up recovery and reducing the wear on SSD storage cells.

2. With an additional redundancy by mirroring user files in their native format to 1 or 2 other destinations using Free File Sync which also can be automized by Windows Task Manager.

3. You can use Win10 O&O Shutup to parametrize Win10 Upgrade and privacy related options. You need to start it as Administrator / with admin rights and then per user account on your system.

My system with 2004 works, but that doesn't mean anything to anyone else, so better wait with the update.

I have this same issue (posted on 6/17/2020 at https://forum.rme-audio.de/viewtopic.ph … #p155954).

@milonet2k (https://forum.rme-audio.de/viewtopic.ph … 61#p157461) and I have compared notes and what we have a workaround but not a fix -> start and stop playback while using the ADI-2 DAC and no BSOD.

However, stop playing the ADI-2 DAC and then power it off -> BSOD.

Roon is the software I am using. They are aware of the issue as well, posted there at the same time as here. Now that it happening with other software, it seems less likely that Roon is the issue and more likely that the RME driver is the issue.

I don't understand the reason for saying rollback or wait - that does not make sense for 3 reasons
1) The previous version (1909) is not available from MS.
2) Deferring the upgrades may not be wise from a security and/or stability standpoint.
3) I understood RME to be an excellent vendor (from ASR) w/r/t quality, firmware and driver updates, hence my purchase.

It would help to explain the rationale behind not investigating this issue now that more than one person has acknowledged my original complaint, e.g., resource driven, not enough complaints, etc. That would be a good thing to know at this point and going forward to set expectations.

To test the MS hypothesis, I roll forward on new windows 10 builds as they become available, yesterday to build 20180, to no avail. I reinstalled drivers and Roon in each incarnation. So waiting for an MS fix may not be a solid strategy. 

Please take this seriously. 

Thanks.

=================================

FYI: Below is a dump off an intel machine different from my original post (motherboard, gfx card, peripherals, etc.). I used this machine to confirm the issue was not specific to that computer, but was repeatable on another. Let me know if you need any more details.

******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

PFN_LIST_CORRUPT (4e)
Typically caused by drivers passing bad memory descriptor lists (ie: calling
MmUnlockPages twice with the same list, etc).  If a kernel debugger is
available get the stack trace.
Arguments:
Arg1: 000000000000009a,
Arg2: 0000000000206655
Arg3: 0000000000000006
Arg4: 0000000000000002

Debugging Details:
------------------

KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.mSec
    Value: 3890

    Key  : Analysis.DebugAnalysisProvider.CPP
    Value: Create: 8007007e on YOLKS

    Key  : Analysis.DebugData
    Value: CreateObject

    Key  : Analysis.DebugModel
    Value: CreateObject

    Key  : Analysis.Elapsed.mSec
    Value: 12655

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 90

    Key  : Analysis.System
    Value: CreateObject

    Key  : WER.OS.Branch
    Value: vb_release

    Key  : WER.OS.Timestamp
    Value: 2019-12-06T14:06:00Z

    Key  : WER.OS.Version
    Value: 10.0.19041.1

ADDITIONAL_XML: 1

OS_BUILD_LAYERS: 1

BUGCHECK_CODE:  4e

BUGCHECK_P1: 9a

BUGCHECK_P2: 206655

BUGCHECK_P3: 6

BUGCHECK_P4: 2

CUSTOMER_CRASH_COUNT:  1

PROCESS_NAME:  System

STACK_TEXT: 
ffff9c8e`63e5eeb8 fffff807`7542b131     : 00000000`0000004e 00000000`0000009a 00000000`00206655 00000000`00000006 : nt!KeBugCheckEx
ffff9c8e`63e5eec0 fffff807`7526f2e6     : ffffea61`42171c50 ffff9c8e`63e5f030 ffff9c8e`00000002 ffffea75`00000000 : nt!MiDeleteNonPagedPoolPte+0x1bbd21
ffff9c8e`63e5ef30 fffff807`752692fa     : 000141b6`00000000 00000000`00000000 00000000`00000000 ffff9c8e`63e5f500 : nt!MiClearNonPagedPtes+0x162
ffff9c8e`63e5f160 fffff807`75269362     : 00000000`00000000 ffff9c8e`63e5f2d1 ffffffff`ffffffdf 00000000`00004000 : nt!MmFreePoolMemory+0x1aa
ffff9c8e`63e5f1e0 fffff807`7526df8a     : 00000000`0000000c 00000000`00000000 00000000`00000000 00000000`00000000 : nt!RtlpHpEnvFreeVA+0x12
ffff9c8e`63e5f210 fffff807`7526afc3     : 00000000`00000001 ffff8300`019cdd00 00000000`0000000f 0000000f`fffffffc : nt!RtlpHpFreeVA+0x3a
ffff9c8e`63e5f250 fffff807`752a617e     : 00000000`00000000 00000000`ffffffdf 00000000`00000000 00000000`ffffff77 : nt!RtlpHpSegMgrCommit+0x1e3
ffff9c8e`63e5f320 fffff807`75268411     : ffffc284`00000001 ffffc284`2e300040 00000000`00000068 00000000`00000021 : nt!RtlpHpSegPageRangeCommit+0x1ee
ffff9c8e`63e5f3c0 fffff807`75267eab     : ffffffff`ffffffff 00000000`00000021 ffffffff`ffffffff ffffc284`1f5ff000 : nt!RtlpHpSegPageRangeCoalesce+0x1b1
ffff9c8e`63e5f440 fffff807`75240dc2     : 00000000`00000000 ffffc284`0fe00100 00000000`2e300000 00000000`00000000 : nt!RtlpHpSegPageRangeShrink+0xeb
ffff9c8e`63e5f4b0 fffff807`759c2019     : 00000000`00000000 00000000`00000000 ffffc284`2d2cf250 01000000`00100000 : nt!ExFreeHeapPool+0x6b2
ffff9c8e`63e5f590 fffff807`73087d36     : ffffc284`2d2c0082 ffffc284`00000001 ffffc284`00000000 fffff807`7520198e : nt!ExFreePool+0x9
ffff9c8e`63e5f5c0 ffffc284`2d2c0082     : ffffc284`00000001 ffffc284`00000000 fffff807`7520198e 00000000`00000000 : madiface_usb_64+0x7d36
ffff9c8e`63e5f5c8 ffffc284`00000001     : ffffc284`00000000 fffff807`7520198e 00000000`00000000 00000000`00000001 : 0xffffc284`2d2c0082
ffff9c8e`63e5f5d0 ffffc284`00000000     : fffff807`7520198e 00000000`00000000 00000000`00000001 ffffc284`274d2a70 : 0xffffc284`00000001
ffff9c8e`63e5f5d8 fffff807`7520198e     : 00000000`00000000 00000000`00000001 ffffc284`274d2a70 ffff8a8c`a7603750 : 0xffffc284`00000000
ffff9c8e`63e5f5e0 fffff807`7308df09     : ffffc284`2d2c51a0 ffffc284`2d2c53c0 ffffc284`0fdfd120 ffffc284`0fdfd120 : nt!HalPutDmaAdapter+0xe
ffff9c8e`63e5f610 ffffc284`2d2c51a0     : ffffc284`2d2c53c0 ffffc284`0fdfd120 ffffc284`0fdfd120 00000000`00000000 : madiface_usb_64+0xdf09
ffff9c8e`63e5f618 ffffc284`2d2c53c0     : ffffc284`0fdfd120 ffffc284`0fdfd120 00000000`00000000 ffffc284`2d2c5418 : 0xffffc284`2d2c51a0
ffff9c8e`63e5f620 ffffc284`0fdfd120     : ffffc284`0fdfd120 00000000`00000000 ffffc284`2d2c5418 ffffc284`2d2c5050 : 0xffffc284`2d2c53c0
ffff9c8e`63e5f628 ffffc284`0fdfd120     : 00000000`00000000 ffffc284`2d2c5418 ffffc284`2d2c5050 fffff807`7308d934 : 0xffffc284`0fdfd120
ffff9c8e`63e5f630 00000000`00000000     : ffffc284`2d2c5418 ffffc284`2d2c5050 fffff807`7308d934 ffffc284`24643300 : 0xffffc284`0fdfd120

SYMBOL_NAME:  madiface_usb_64+7d36

MODULE_NAME: madiface_usb_64

IMAGE_NAME:  madiface_usb_64.sys

STACK_COMMAND:  .thread ; .cxr ; kb

BUCKET_ID_FUNC_OFFSET:  7d36

FAILURE_BUCKET_ID:  0x4E_9a_madiface_usb_64!unknown_function

OS_VERSION:  10.0.19041.1

BUILDLAB_STR:  vb_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {26aff8c8-385d-5a05-dd39-344a3842bb30}

Followup:     MachineOwner
---------

Hi,
Had the exact same problem after updating win10 to 2004, only workaround I've found was to roll back win10.
Didn't try the "safe remove", it didn't even come to my mind as I've had zero problems with powering off before

I have been using the RME ADI2 DAC Fs from 2018.

Since my computer updated to Windows 10 2004, I had a BSOD issue today. I use RME drivers, ASIO and Foobar2000 to play music. The BSOD happened when I paused the music in Foobar2000 and switched off the RME Dac.

I then uninstalled the RME drivers, to see if there is a problem with the Windows 10 class compliant mode. The BSOD problem is not there even if I do the same process as before - that is play music in Foobar2000, pause it and then switch off the RME Dac. Of course, I am using the DirectSound output in Foobar2000 since the RME drivers are not installed.

However, in the audio settings panel for the RME output, I am not able to see all the various sample rates - I am not even able to change the sample rate. I only have one entry at 32 bit 48000hz. Both for playback and recording.

Other than rolling back to a previous version of Windows, is there anything else I can do?

Thanks,

Is it normal also that in class compliant mode I get only one sample rate of 48k with 32 bit. I remember this was not the case in the past.

Maybe again something to do with the latest version of Windows 10 2004?

[emphasis added]

Good information. It would have been useful to know before I purchased the device - I could not have used it;  here is a typical use case to show why: 
              I want to listen to some music using a DAC/Amp (DAC). I turn the DAC on and plug in a pair of headphones, select the DAC on my Roon Remote app, select the music and start playback. When I  am done, I power off the DAC and leave the server running. With the ADI-2 DAC, that last activity, in bold, results in a BSOD.

So the "expected, normal...[use]" quoted above does not reflect how Roon interoperates with devices; as the server, it stays running all the time. Clients attach and may direct the server to access any connected and powered on device. As a result the devices must be able to be powered on/off as needed and do so w/out crashing the server.

In other words, Roon users may have any number of devices connected and in use simultaneously. Requiring that the server exit before one of the devices can be powered off is not practical.  This "expected, normal..[use]" was not necessary before Windows 10 build 2004, nor can I find reference to it in the manual. (btw: an excellent document).

Okay, resource limitations during summer; understandable. Thank you for acknowledging that you will look into it and for setting some expectations about when that might happen.

As an aside, other Roon users with ADI-2 DACs may be interested having some level of dialog between the two companies to increase compatibility. RME has received positive recommendations from the user community since ~2018.

Food for thought.

Finally, please let me know if I missed something.

I am happy to see that Class compliant is still ok on Windows 10 2004. Thanks for those screenshots.

Can I just clarify for future use the correct method to uninstall the RME drivers, as to me at least the instructions in the manual are not clear enough.

There are 2 apps that get installed namely the "RME Madiface USB" and another one called the "Windows driver package ...". It is possible to uninstall these from the Settings option in the computer in the Apps section. Is there a specific order in which these two have to be uninstalled. For example, if I uninstall the "RME Madiface USB" app first, then I am unable to uninstall the "Windows driver package ..." as it gives an error message. The reverse order uninstalls both the apps.

There is also the other option of uninstalling from the Device Manager. There if I uninstall the RME sound controller, along with its drivers, it still does not uninstall the apps. I am then able to only uninstall the "RME Madiface USB" app, but not the "Windows driver package ..." app - I get an error message.

Is it possible to provide a step by step approach to uninstall the RME drivers. I do not see this as super important as I usually use the RME drivers. So maybe something to consider when updating the manual the next time?

Thanks for confirming the issue.  FYI, If there is a need to contact Roon my issue report is queued for their hardware team via \@noris on that site. 

So the different ASIO driver may resolve the issue for Roon as well.. that's good news.

I don't use Roon, but the win10 2004 issue happened with Audirvana for me

We just released Windows driver version 0.9722. This one fixes the BSOD on Surprise Removal with Windows 2004 if ASIO is not completely released. Or more simple: the topic of this thread should be fixed.

http://www.rme-audio.de/downloads/drive … _09722.zip

Connect ADI, turn it on, reinstall the new driver, then reboot. The Settings dialog does list the correct driver version, so your installation did not work correctly.

Hi MC! I am updated to the latest driver on my new ADI-2 DAC yesterday, it worked fine.

But today after a starting my PC again my new ADI-2 DAC fs doesn't show up anymore as an audio device (Audiogeräte verwalten/Ausgabegeräte).  Under device manager RME ADI-2 DAC shows up under "Audio, Video, Gamecontroller", but not under Audioinputs- / Outputs (Audioeingänge und -ausgänge)

Under "Bluetooth- and other devices" I see ADI-2 DAC (59740065) and AK5370.

Here is a screenshot: https://imgur.com/a/l4QrMsW

I tried uninstalling the new driver -> rebooting -> installing the previous driver, but then I get an installation error.
Is there a logfile? How can I get the old driver installed?
What can I do?

Windows 10 2004
Latest driver 09721 and firmware 23 usb/34 dsb.
Source is set to Auto on the DAC.

Sorry, if this is the wrong thread, but with the old driver, I didn't encounter that problem.
Thank you!

- Paul

:: edit ::
After fully uninstalling the drivers from device manager, rebooting and installing the new drivers I now see Analog and SPDIF, but still no USB: https://imgur.com/uXDQfCN

Thank you for the quick answer, MC. :-)

From device manager I clicked on "Move to previous driver" and then manually installed the RME driver from device manager.
This made the digital connection show up again under windows sound output devices!
Just reinstalling 0.9721 and restarting didn't work.

Sadly now the RME ADI-2 DAC is gone again from sound output devices (Sound/Ausgabe/Ausgabegerät auswählen)!
I had used the onboard audio for a quick skype call inbetween.

I just reinstalled 0.9721 and restarted. Didn't work. No RME device/madiface under output devices.

I don't have any other specific audio drivers installed. I could install the Realtek drivers for the Asus Onboard drivers... not that I really want to. Besides that I plan to reinstall Windows on a new drive next month, but this system is pretty clean.

Is there anything I could do to help resolve the problem in the mean time?

Hello.Are you planning to release a new ADI 2 DAC on, for example,AK499? Excuse me,I wrote to this section because I didn't find the one I needed.

That did the trick. Thanks.

@MC, Although your note does not imply or state it, the new driver moves us closer to  fixing the BSOD with ASIO . I tested it and had one initial BSOD, but after that none. The rest of this message caveats that statement.

To test, I toggled playback between the ADI-2 and another device, while power cycling the ADI-2 off during playback and when idle. It should have crashed when powered off at idle and it did so after the 4th round.

What is odd is that this driver behaves inconsistently, as shown in Roon; when powered off; sometimes it disappeared immediately at power off (normal behavior) and others it would not (abnormal).  The one BSOD occurred when I started playback to one of these "phantom"  drivers that remained after the ADI-2 was powered off.  It had the same error message as the others.

Unfortunately,  the outcome (BSOD or not) is unpredictable. Only the one occurred - other times I've tried playback to the phantom, Roon will continue to playback to the phantom. When this occurs, and the DAC is powered back on and playback started, playback may appear to be occurring but no audio will be sent to the DAC (e.g., meters do not move). This can be corrected by setting up the DAC again in Roon. After that, it sees the real DAC and everything works fine.

When the system rebooted after the BSOD, I checked to be sure everything was installed properly and began testing again. The driver still behaves inconsistently but no BSOD's have occurred at this time.

At least now I can start to use ASIO again.

Hope this helps.

Thanks for doing this.

Thanks for the explanation and it make  sense its not an RME issue. If I don't try to use it, I'll likely be fine....

Done.

Thanks again.

Interesting. In addition to telling Roon about the new driver, I relayed the results of my testing so they could take a look at it. Adding your comment to it will give them a place to start.

I will do that now.

Thanks again.