Using audio stack from Windows 2000/XP/2003, MS winmm writes data to the wrong registry keys

This is a follow-up of CORE-17361.

To reproduce the problem, you need to simply replace the following components by versions from Windows:

• from XP/2003: ac97.sys (rename from ac97intc.sys), drmk.sys, kmixer.sys, ks.sys, portcls.sys, swenum.sys, sysaudio.sys, wdmaud.sys, wdmaud.drv.
• from 2000: winmm.dll.

And then reboot.

After that, winmm.dll fails to enumerate audio devices with the following error:

WINMM: (pid bc) SetupDiGetClasDevs failed [0x00000002]. 

which repeats many times in a loop, because it's most likely a part of the internal enumeration loop.
See winmm.log for details.

Also, the wrong registry subkeys are created inside HKLM\SYSTEM\CurrentControlSet\Control\DeviceClasses

##?#PCI#VEN_8086&DEV_2415&SUBSYS_00008086&REV_01#3&609b8881&05#{6994ad04-93ef-11d0-a3cc-00a0c9223196}#Topology and #Wave subkeys\Device Parameters subkey. SetupPreferredAudioDevicesCount value actually exists there, and not anywhere else:

But in ReactOS, it writes them incorrectly:

My investigations show these keys are created and managed by our setupapi, and the function which is responsible for opening the key and returning a handle to it, is SetupDiCreateDeviceInterfaceRegKeyW(). In this case, it's called from MS winmm directly, not from our setupapi internally or from somewhere else. The problem is, our implementation of this function returns a handle to a device instance key (the next key contained inside the class GUID key), instead of a Device Parameters subkey. MS winmm expects to open that key and then write the value there, but since we're returning a handle to a wrong registry key in that function, it creates the wrong keys and writes the needed values there instead. That's why those keys are created, what subsequently causes those SetupDiGetClassDevsExW() to fail when it finds those incorrect keys in registry and then fails to read required data from them, because it's simply missing (since only the REG_DWORD value is written there).
What is interesting, if to delete those keys manually, MS winmm does not fails because of our setupapi!SetupDiGetClassDevsExW() anymore, but only until the next reboot, when the keys are created again and again, so winmm is failing again too.
This is also confirmed by Wine implementation (the function creates/opens a Device Parameters subkey there too): https://github.com/wine-mirror/wine/blob/29446a66ce2aab5d03320d8b8eb425213b84727f/dlls/setupapi/devinst.c#L2847.

I already made a patch with a fix for this and want to send a new PR soon. In my patch, I fixed SetupDiCreateDeviceInterfaceRegKeyW() function itself and corrected its usage inside internal InstallOneInterface() helper, which is called from SetupDiInstallDeviceInterfaces(). TODO: probably update its usage in our streamci too (is it actually needed?): https://git.reactos.org/?p=reactos.git;a=blob;f=dll/win32/streamci/streamci.c;hb=a1a169fbe811b621188b41c907c8ef51304644cb#l168.

I can confirm: after applying my changes, it writes SetupPrefrredAudioDevicesCount value in Device Parameters subkey, as it should. As result, winmm is not failing anymore and it finishes enumeration of audio devices successfully:

Some debugging output with checked winmm.dll from Windows 2000 SP4:

WINMM: (pid bc) WndProcPnpNotify: RegisterDeviceNotification successful

WINMM: (pid bc) PnpInfoEnum:Enumerated[\\?\PCI#VEN_8086&DEV_2415&SUBSYS_00008086&REV_01#3&609b8881&05#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\Topology]

WINMM: (pid bc) MNDS: SetupDiOpenDeviceInfo failed, LastError=-536870389

WINMM: (pid bc) MNDIS: Success

WINMM: (pid bc) PnpInfoEnum:Enumerated[\\?\PCI#VEN_8086&DEV_2415&SUBSYS_00008086&REV_01#3&609b8881&05#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\Wave]

WINMM: (pid bc) MNDS: SetupDiOpenDeviceInfo failed, LastError=-536870389

WINMM: (pid bc) MNDIS: Success

WINMM: (pid bc) PnpInfoEnum successful 

SetupDiOpenDeviceInfo() failure is another problem and it seems to be unrelated to this one.
The same effect can be also reached by simply deleting wrong keys, but since they are created again and again after reboot, it's just a workaround but definitely not a correct solution. It needs to fix the root cause of why the wrong keys are created instead.