Guys,
I think I found a bug in the passthru sample (or in ndis/ndiswan), on vista.
The sample deadlocks into PtUnbind, on the call to
NdisIMDeinitializeDeviceInstance(), in this scenario.
- Install passthru (e.g. with bindview)
- setup a PPTP vpn, and connect to the VPN server
- while the PPTP connection is active, try to uninstall passthru (e.g. with
bindview)
The passthru sample deadlocks all the time calling
NdisIMDeinitializeDeviceInstance() on the binding on the NDISWANIP miniport
(i.e. the ndiswan miniport that delivers the packets of a pptp connection
and issues the WAN_LINE_UP/DOWN messages to ProtocolStatus()).
I’m able to consistently replicate the issue on a freshly installed Vista
RTM x86 machine and the passthru coming from WDK 6000 (but the same happens
on the passthru from DDK 2K3SP1).
The problem doesn’t seem to happen on a XP SP2 environment.
Can anyone (some MS folk??) give me any hint on what to do/contact?
Have a nice day
Gianluca Varenni
CACE Technologies
On Nov 17, 2006, at 12:50 PM, Gianluca Varenni wrote:
Guys,
I think I found a bug in the passthru sample (or in ndis/ndiswan),
on vista.
The sample deadlocks into PtUnbind, on the call to
NdisIMDeinitializeDeviceInstance(), in this scenario.
- Install passthru (e.g. with bindview)
- setup a PPTP vpn, and connect to the VPN server
- while the PPTP connection is active, try to uninstall passthru
(e.g. with
bindview)
The passthru sample deadlocks all the time calling
NdisIMDeinitializeDeviceInstance() on the binding on the NDISWANIP
miniport
(i.e. the ndiswan miniport that delivers the packets of a pptp
connection
and issues the WAN_LINE_UP/DOWN messages to ProtocolStatus()).
I’m able to consistently replicate the issue on a freshly installed
Vista
RTM x86 machine and the passthru coming from WDK 6000 (but the same
happens
on the passthru from DDK 2K3SP1).
The problem doesn’t seem to happen on a XP SP2 environment.
Can anyone (some MS folk??) give me any hint on what to do/contact?
Wow, that sounds bad. I assume you tried an unmodified passthru +
unmodified INFs for install? I’ve tested my IMs a bit on Vista and
haven’t run into this, but I don’t know if I’ve hit this particular
case.
Please let us know what you find out.
-Steve
“Steve Dispensa” wrote in message
news:xxxxx@ntdev…
> On Nov 17, 2006, at 12:50 PM, Gianluca Varenni wrote:
>
>> Guys,
>>
>> I think I found a bug in the passthru sample (or in ndis/ndiswan), on
>> vista.
>>
>> The sample deadlocks into PtUnbind, on the call to
>> NdisIMDeinitializeDeviceInstance(), in this scenario.
>>
>> 1. Install passthru (e.g. with bindview)
>> 2. setup a PPTP vpn, and connect to the VPN server
>> 3. while the PPTP connection is active, try to uninstall passthru (e.g.
>> with
>> bindview)
>>
>> The passthru sample deadlocks all the time calling
>> NdisIMDeinitializeDeviceInstance() on the binding on the NDISWANIP
>> miniport
>> (i.e. the ndiswan miniport that delivers the packets of a pptp
>> connection
>> and issues the WAN_LINE_UP/DOWN messages to ProtocolStatus()).
>>
>> I’m able to consistently replicate the issue on a freshly installed
>> Vista
>> RTM x86 machine and the passthru coming from WDK 6000 (but the same
>> happens
>> on the passthru from DDK 2K3SP1).
>>
>> The problem doesn’t seem to happen on a XP SP2 environment.
>>
>> Can anyone (some MS folk??) give me any hint on what to do/contact?
>
> Wow, that sounds bad. I assume you tried an unmodified passthru +
> unmodified INFs for install? I’ve tested my IMs a bit on Vista and
> haven’t run into this, but I don’t know if I’ve hit this particular case.
I discovered the problem with my IM driver as well, and I thought it was a
bug in my code. So I tried the unmodified passthru from ddk 3790.1830, same
issue.
I moved to WDK6000 and related passthry i saw the code was changed a bit
(some ref counting was added on the PADAPT structure), same issue. I
actually saw the issue on RC2 as well, the day vista went RTM. So I waited
to have the final bits, hoping it got fixed after RC2. I’m still hoping it’s
a passthru bug, and not an ndiswan one…
Eliyas, Doron, help!
Have a nice day
GV
>
> Please let us know what you find out.
>
> -Steve
>
>
Things might get a little slow on this end- virtually everyone working on Vista got this entire next week off with pay, and if the parking lot is a good indicator, quite a few people have also begun taking vacation they deferred while working on it. I have forwarded GV’s original post to the NDIS team. But it may be a while before you hear anything back on it.
But I could be wrong- there are always a few people on any holiday, after all, and some of them may be able to help sooner…
> I moved to WDK6000 and related passthry i saw the code was changed
a bit
(some ref counting was added on the PADAPT structure),
Ooooh, that’s interesting. I ran across this bug a while ago and have
been meaning to write it up. Too bad they didn’t also document the
(particularly interesting) race conditions that led them to adding
the reference counting. It was a lot of fun finding that particular
race. 
There’s actually another potential race related to reference counting
in passthru, but it’s not triggered by the out-of-the-box driver: the
control device object that’s created by NdisMRegisterDevice() has a
different lifetime than the miniport itself, so if you happen to have
an I/O stuck in a dispatch routine while (or after) your MPHalt runs,
you crash. I wrote this up a few months ago:
http://kernelmustard.com/2006/09/13/ndismregisterdevice-and-object-
lifetimes/
same issue. I
actually saw the issue on RC2 as well, the day vista went RTM. So I
waited
to have the final bits, hoping it got fixed after RC2. I’m still
hoping it’s
a passthru bug, and not an ndiswan one…
There, I have to disagree: if it’s actually a passthru bug, *tons* of
shipping code from dev shops large and small will break; if, on the
other hand, it’s an OS component, we might get an auto-distributed
patch. Which is likely to make it to more machines?
-Steve
----- Original Message -----
From: “Steve Dispensa”
To: “Windows System Software Devs Interest List”
Sent: Friday, November 17, 2006 10:18 PM
Subject: Re: [ntdev] Possible bug in the passthru sample and/or Ndis.sys
VISTA x86
>> I moved to WDK6000 and related passthry i saw the code was changed a bit
>> (some ref counting was added on the PADAPT structure),
>
>
> Ooooh, that’s interesting. I ran across this bug a while ago and have
> been meaning to write it up. Too bad they didn’t also document the
> (particularly interesting) race conditions that led them to adding the
> reference counting. It was a lot of fun finding that particular race.
>
> There’s actually another potential race related to reference counting in
> passthru, but it’s not triggered by the out-of-the-box driver: the
> control device object that’s created by NdisMRegisterDevice() has a
> different lifetime than the miniport itself, so if you happen to have an
> I/O stuck in a dispatch routine while (or after) your MPHalt runs, you
> crash. I wrote this up a few months ago:
>
> http://kernelmustard.com/2006/09/13/ndismregisterdevice-and-object-
> lifetimes/
>
I actually haven’t looked at the patches they did. But I do know about the
problem of the control device being decoupled from the ndis bindings. And in
fact my driver has a reference counting system similar to the one that they
seem to have put in the new passthru. I need to check if i cover the same
race conditions they cover and the other way around…
>
>> same issue. I
>> actually saw the issue on RC2 as well, the day vista went RTM. So I
>> waited
>> to have the final bits, hoping it got fixed after RC2. I’m still hoping
>> it’s
>> a passthru bug, and not an ndiswan one…
>
> There, I have to disagree: if it’s actually a passthru bug, tons of
> shipping code from dev shops large and small will break; if, on the other
> hand, it’s an OS component, we might get an auto-distributed patch. Which
> is likely to make it to more machines?
>
You’re right… it’s a pain if the bug is in passthru because of the large
number of IMs based on that (who dares writing an IM from scratch?!?). And
it will be sort of shame if the new vista has already a known kernel level
bug. Even if they can easily release a patch thru windowsupdate…
Have a nice day
GV
> -Steve
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer