Hi guys, thanks for your reply Tim, your answers are always short but informative :) Over the last days, I have made huge progress in understanding KS and especially PortCls. I still can't however create a MIDI port that can be found using midiInGetDevCaps. I am probably missing something very important in correct startup of the driver. Apparently, you don't necessarily need to have interfaces defined in your inf files. I looked at a couple of inf files of my midi keyboards here and none of them defines any interfaces (except one driver, which specifies his topology interface). MSDN says: "When enumerating MIDI input or output devices through the Windows Multimedia midiInXxx or midiOutXxx functions, an application can see only WDM devices whose miniport drivers expose MIDI pins." (http://msdn.microsoft.com/de-de/library/windows/hardware/ff537520%28v=vs.85%29.aspx) right, I have done that, I pretty much use the Pin factory from the DMusUart sample, that should do just fine for now. I wonder, when a Midi Stream in the miniport is supposed to be created and by who. Will the OS call the newStream function when the driver is completely loaded or when a client connects to the midi port? Or do I need to create it in some kind of ISR? I haven't worried too much about the Interrupts as it wasn't well documented in the audio section (the only thing I found there was how to notify the Port that a hardware interrupt was triggered) and the sample didn't seem to do very much in the ISRs. Any ideas would be great, Max Date: Wed, 5 Jun 2013 14:50:50 -0700 From: timr@xxxxxxxxx To: wdmaudiodev@xxxxxxxxxxxxx Subject: [wdmaudiodev] Re: StartDevice Empty Resource List? Max K wrote: okay after more programming and research I have now my own, specialized, version based on Eugenes code and the devcon install sample code, i used a few more updated funtions. However I couldn't notice any part where a PDO is created, maybe in the SetupDiCallClassInstaller function? Yes. "Devcon install" creates a structure in memory, and SetupDiCallClassInstaller creates the kernel structures that result in your driver being loaded. >> I use DPInst to do my pre-installs well aparently the Class Installer called by devcon copies the .sys to system32/drivers already, so what use DPInst for? If you use "devcon install" you don't need DPInst. However, you can't distribute devcon.exe with your driver packages, so when you want this to be used by other people, you'll need something else. So a few new questions pop up: Also you mentioned that you could use either the PNP or a Service Manager, which one is preferred? The multimedia device classes require the use of device interfaces. Those will only work in a PnP driver. Is there a tool that i can use to display the PDOs on the various busses? The registry has them all, but it includes devices that existed in the past but don't right now. You can get this information from the kernel debugger. Do I need to recreate the PDO on each system start? The device that "devcon install" creates is tucked in the registry in CurrentControlSet\Enum, and should be re-created on each boot. -- Tim Roberts, timr@xxxxxxxxx Providenza & Boekelheide, Inc.