Problems using winsock within UMDF driver

Greg_Thomson · January 18, 2007, 12:38am

I’m attempting to perform a winsock send() within a UMDF driver and the host
process (WudfHost.exe) throws the exceptions as below. Any suggestions on
how I might debug this better? Any suggestions on using winsock within a
UMDF driver? I’ve been around the block on this one a few times… using
WSASend() instead of send(), executing winsock code in a separate thread
outside the UMDF callbacks, etc. Everything seems to yield the same
exceptions…

Debug Output… (driver based on echo sample)

SerialHub: CMyQueue::OnWrite

‘WudfHost.exe’: Loaded ‘C:\WINDOWS\system32\winsflt.dll’, Binary was not
built with debug information.

‘WudfHost.exe’: Loaded ‘C:\WINDOWS\system32\shlwapi.dll’, No symbols loaded.

‘WudfHost.exe’: Loaded ‘C:\WINDOWS\system32\shell32.dll’, No symbols loaded.

‘WudfHost.exe’: Loaded
‘C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03\comctl32.dll’,
No symbols loaded.

‘WudfHost.exe’: Loaded ‘C:\WINDOWS\system32\comctl32.dll’, No symbols
loaded.

‘WudfHost.exe’: Loaded ‘C:\WINDOWS\system32\mswsock.dll’, No symbols loaded.

‘WudfHost.exe’: Loaded ‘C:\WINDOWS\system32\hnetcfg.dll’, No symbols loaded.

‘WudfHost.exe’: Loaded ‘C:\WINDOWS\system32\wshtcpip.dll’, No symbols
loaded.

The thread ‘Win32 Thread’ (0x68c) has exited with code 0 (0x0).

‘WudfHost.exe’: Loaded ‘C:\WINDOWS\system32\secur32.dll’, No symbols loaded.

…winsock correctly initialized, bound and connected at this point. Then a
send() is attempted…

First-chance exception at 0x7c812a5b in WudfHost.exe: Microsoft C++
exception: exception at memory location 0x0071f2ac…

…the send() function sucessfully completes as below, but the host
eventually becomes corrupt…

SerialHub: 7 character(s) sent successfully

OSR_Community_User · January 18, 2007, 12:57am

Have you attached a debugger to the service, and enabled first-chance exceptions, and had a chance to examine this exception when it occurs?

I realize debugging a service process can be difficult. And I’m ignorant of how the WudfHost.exe process is created, but I assume it is either directly launched by the Service Control Manager, or is launched indirectly by a UMDF service process.

In either case, you’ll need to get a debugger attached to the process, and you’ll need to set up the debugger so that it halts on first-chance exceptions, for the set of exceptions that you’re interested in. I would recommend using the “Image File Execution Options” way to enable automatically launching a process under a debugger. If you search the NTDEV archives, I posted a few long-ish messages on how to do this. Long story short, go to “HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options”, and create a subkey named “WudfHost.exe”. In that subkey, create a REG_SZ value named “Debugger” whose value is something like “c:\dbg\cdb.exe -server tcp:port=4000”. CreateProcess looks for this registry string when it launches a process, and if the “Debugger” value is there, it will concatenate the “Debugger” string with the original command line, and execute that process instead. This allows the debugger to be launched, no matter how the process in question is launched. The only limitation to this technique is that you can only choose which processes to launch under a debugger based on the filename of the executable. So if you need to debug only one instance of foo.exe, you need to choose a different means to debug.

Next, you’ll want to make sure that first-chance exceptions are enabled. You can do this by modifying the command-line that you pass to cdb.exe. Add “-xe vcpp” to enable exceptions for the VC++ exception, or replace “vcpp” with any other exception, either using the names or hex values of the exceptions. (This is exactly equivalent to “sxe vcpp” from within the debugger. Read the “Controlling Exceptions and Events” page in debugger.chm for more info.) You’ll need to add this before the -server statement.

Next, choose whether you want the process to launch without waiting for you to connect to the debugger and resume, or whether you do want it to wait. If you want it to run without waiting, use “-g”. And similarly, use “-G” to allow the process to exit without the debugger interfering. So, the full “Debugger” command-line might resemble:

c:\dbg\cdb.exe -server tcp:port=4000 -xe vcpp -g -G

(NB: The order of arguments here is significant. -server must be first.) Then, start the service, and connect to the debugger:

c:\dbg\windbg -remote tcp:port=4000,server=127.0.0.1

This, or some variant of it, should let you catch the exception under a debugger. If you need help getting this working properly, send me mail off-list and I’ll do what I can to help you get set up.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Greg Thomson
Sent: Thursday, January 18, 2007 12:38 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Problems using winsock within UMDF driver