Approach 2 is the way to go, but it looks like you haven’t got it right.
Do check to insure that the user memory involved in reading IN data is persistent until the read completes.
If you are using an OVERLAPPED structure, don’t allocate it on the stack. Don’t have your read buffer on the stack.
Take a look at some of the WDK documentation and samples that perform asynchronous I/O.
Good luck,
Thomas F. Divine
From: Alex Brown
Sent: Friday, September 10, 2010 7:18 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Virtual KMDF and IPC to application in userland
Hi Again,
I need a little more guidance. so far I have managed to respond the the various URB requests and get to the stage where I’m getting bulk transfers.
so far the Bulk OUT is working OK. I can read the buffer the child driver has sent and can get the text out using kdPrint (I know this is dangerous and its not staying, it was just a test)
what has stumped me is the IN. I have tried a number of approaches when handling this one
Approach 1:
a… Request comes in
b… Look to see if data is available
c… if data is available send, else complete the request with .TransferBufferLength=0;
This caused the system to hit 100% CPU usage, hard to tell what was happening but I am assuming USBSER.sys (the child driver) was continually sending IN requests
Approach 2:
a… Request comes in
b… If no data is available forward the request to a manual queue
c… when data is available grab the request, copy data to .TransfereBuffer, set .TransferBufferLength and complete the request
The problem I get with this approach is I get a bug check (0c0000008F, 0xC0000005) Access Violation when i’m trying to read or write to the urb. The urb has been pulled from the requests parameters.
Approach 3:
a… When an in request comes in poll to see if data has arrived.
It did not suppose me that this locked the CPU to 100% and didn’t work. I couldnt find a way of putting the thread to sleep (sorry about the terminology, I’m used to .net) so other threads could use the cpu.
At the moment the data to be sent on an IN request is being generated by the driver. its a bit dumb at the moment, just trying to sent OK when I see a on the OUT transaction.
Any help is appreciated
On 7 September 2010 16:46, Alex Brown wrote:
I’m not fining it as bad as I initally thought I would Chris.
Its knowing things like you need to look for internal IOCTLS. I am happy with the approch I am taking.
The applications connecting to the COM port will be expecting it to be a modem so I think its the right choice.
Just for interest, the two things we found before with usbser:
1) we got over this detachment problem in the end.
2) The issue we saw was caused by usbser not throttling. So mscomm.osx (groan) thought we where connected at 9600 baud. our application send 64bytes in every read. this lead to vb6 and mscomm falling over. We switched to a .net com port that could handle a full 2Mbp/s when connected at 9600.
We also throttled the data back at the embedded device end 
On 7 September 2010 16:37, wrote:
Alex Brown wrote:
> the problem I have at the moment is getting my PDO to respond
> to any requests what so ever.
>
> I am implementing the Read, write and IOControl events but none
> of the[m] fire.
Right: you’re actually going to want to watch for internal IOCTL requests, namely of the kind seen here:
http://msdn.microsoft.com/en-us/library/ff537421(VS.85).aspx
The vast majority of them will be submit URB internal IOCTLs, which are documented here:
http://msdn.microsoft.com/en-us/library/ff538923(VS.85).aspx
You should expect to respond to these sorts of requests:
1) Get device descriptor
2) Get config descriptor (first 9 bytes, then the whole thing). Your config descriptor should appear as a CDC ACM device as specified in usbcdc11.pdf.
3) Set config (passing back your choice of pipe handle values, etc.)
4) URB_FUNCTION_CLASS_* (for SET_LINE_CODING et. al)
5) URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER (for sending and receiving actual data, both asynchronous notifications i.e. DSR and the actual port data itself)
… and so on
I guess this is a little more complicated than I first thought/remembered, but I still think it will be easier than writing your own serial driver, the serial driver semantics are extremely complicated and very hard to get totally right (especially if you are dealing with esoteric user-mode code like mscomm32.ocx).
Your other alternative is to start with the KMDF serial sample and rip out all the hardware-based lower edge code and replace it with interaction to a raw PDO or control device. However, you would still have to go through all the complexity of defining a contract between usermode and the raw PDO to indicate and receive port data and asynchronous notifications. In my opinion it’s easier to integrate this into essentially a blank slate (your bus driver) rather than placing it into two dozen different spots in a driver that you did not write.
Also, usbser and the WDK serial driver do not behave exactly the same and have different semantics in various situations so if you are dealing with existing code that was using usbser, starting from serial may be painful.
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer