FilterConnectCommunicationPort

Hopefully somebody can offer some insight without my posting a ton of code
because there is only one call involved in this problem...

From a user mode .DLL, I'm loading a minfilter driver. All is well. The
driver creates a communication port. Again, all is well. The .DLL calls
FilterConnectCommunicationPort. The driver acknowledges receipt (via
DbgPrint) in its MessageCallback function. It returns Status_Success.

Our story ends here. The FilterConnectCommunicationPort function never
returns. The .DLL thread is dead and locked. The mouse still works, the
keyboard works, but it appears Windows won't leave the kernel thread to
return to user mode.

Any ideas? Have I accelerated the onset of Armegeddon?

Don
Sun Sep 02 16:38:18 PDT 2007

As this on NTFSD at http://www.osronline.com/ that is the list for file
system questions. I have never use the communication port or would try to
answer here.

Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply


"Dakota Ridge" <DakotaRidge@discussions.microsoft.com> wrote in message
news:B7AC9EEA-BA81-41F1-B56F-E99744842C73@microsoft.com...
> Hopefully somebody can offer some insight without my posting a ton of
> code
> because there is only one call involved in this problem...
>
> From a user mode .DLL, I'm loading a minfilter driver. All is well. The
> driver creates a communication port. Again, all is well. The .DLL calls
> FilterConnectCommunicationPort. The driver acknowledges receipt (via
> DbgPrint) in its MessageCallback function. It returns Status_Success.
>
> Our story ends here. The FilterConnectCommunicationPort function never
> returns. The .DLL thread is dead and locked. The mouse still works, the
> keyboard works, but it appears Windows won't leave the kernel thread to
> return to user mode.
>
> Any ideas? Have I accelerated the onset of Armegeddon?