Doron
Sun Apr 22 01:10:24 CDT 2007
which is why you should not do that either, then again, if you have a handle
to the stack, it is safe b/c the handle has a ref on the stack
d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Anton Bassov" <AntonBassov@discussions.microsoft.com> wrote in message
news:831A58D5-0F83-41AE-BD28-2CCDBF28A284@microsoft.com...
>
>> there is no guarantee that once you get NextDevice that it (the
>> NextDevice)
>> will not be deleted.
>
> This is a good point. However, you can get into exactly the same trouble
> even if you get a pointer by some documented calls , because not all
> documented API increment reference count on the device(for example,
> IoGetAttachedDevice()).
>
>
> Anton Bassov
> "Doron Holan [MS]" wrote:
>
>> there is no guarantee that once you get NextDevice that it (the
>> NextDevice)
>> will not be deleted. You cannot make assumptions on undocumented
>> behavior.
>> Besides, your answer to walk the device list has nothing to do with the
>> problem at hand...
>>
>> d
>>
>> --
>> Please do not send e-mail directly to this alias. this alias is for
>> newsgroup purposes only.
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>> "Anton Bassov" <AntonBassov@discussions.microsoft.com> wrote in message
>> news:9FC4EE71-2E66-41C6-AAD7-BBBAC0F6F42E@microsoft.com...
>> > Doron,
>> >
>> >> the OS can choose to delete the object and update NextDevice.
>> >
>> >
>> > Sorry, but the above statement is just another way of saying "the
>> > system
>> > can
>> > be poorly designed".....
>> >
>> >> just call IoEnumerateDeviceObjectList
>> >
>> > Unfortunately, IoEnumerateDeviceObjectList ()it is not supported on
>> > W2K....
>> >
>> > When MSFT drops any support for W2K life is going to get easier for us
>> >
>> > Anton Bassov
>> >
>> >
>> >
>> > Anton Bassov
>> >
>> > "Doron Holan [MS]" wrote:
>> >
>> >> anton, you are not allowed to walk the list, plain and simple. it
>> >> does
>> >> not
>> >> matter about that atomicity of the instructions, the OS can choose to
>> >> delete
>> >> the object and update NextDevice. it is out of your control how the
>> >> OS
>> >> maintains the list, besided prefast for drivers will give you an error
>> >> you
>> >> touch this field. besides, just call IoEnumerateDeviceObjectList and
>> >> use
>> >> a
>> >> documented method that is safe
>> >>
>> >> d
>> >>
>> >> --
>> >> Please do not send e-mail directly to this alias. this alias is for
>> >> newsgroup purposes only.
>> >> This posting is provided "AS IS" with no warranties, and confers no
>> >> rights.
>> >>
>> >>
>> >> "Anton Bassov" <AntonBassov@discussions.microsoft.com> wrote in
>> >> message
>> >> news:818C0902-51E7-4B20-B53B-9E3DE7F9A251@microsoft.com...
>> >> > Don,
>> >> >
>> >> >> The above method works fine until the system jumps in and adds or
>> >> >> deletes
>> >> >> a
>> >> >> DEVICE_OBJECT from the list, since the lock to control this is
>> >> >> totally
>> >> >> buried you are creating a crash that is going to happen sooner or
>> >> >> later.
>> >> >
>> >> > Unless the system is buggy, you are not going to crash.....
>> >> >
>> >> > If the system is not buggy (i.e. updates NextDevice member of
>> >> > DEVICE_OBJECT
>> >> > X as respectively last and first step upon addition and removal of
>> >> > the
>> >> > device
>> >> > Y), there is no need for a spinlock whatsoever. Updating NextDevice
>> >> > member
>> >> > is
>> >> > just one instruction that is made on the DWORD boundary(please look
>> >> > at
>> >> > the
>> >> > declaration of DEVICE_OBJECT - NextDevice member is 12 bytes away
>> >> > from
>> >> > the
>> >> > beginning of the object, which is always DWORD-aligned), so that the
>> >> > bus
>> >> > gets
>> >> > locked anyway. In other words, unless the system first delets the
>> >> > device
>> >> > Y
>> >> > and then updates NextDevice member of DEVICE_OBJECT X, you just
>> >> > have
>> >> > no
>> >> > chance to get invalid pointer from DEVICE_OBJECT Y's NextDevice
>> >> > member.....
>> >> >
>> >> > Anton Bassov
>> >> >
>> >> > "Don Burn" wrote:
>> >> >
>> >> >>
>> >> >> "Anton Bassov" <AntonBassov@discussions.microsoft.com> wrote in
>> >> >> message
>> >> >> news:6FFFAA01-30A6-4565-9354-849D82A273B0@microsoft.com...
>> >> >> > Actually, there is so much easier way to enumerate children.....
>> >> >> >
>> >> >> >
>> >> >> > Get the DRIVER_OBJECT of the target driver, and walk the list of
>> >> >> > all
>> >> >> > DEVICE_OBJECTs that it has created (DRIVER_OBJECT's DeviceObject
>> >> >> > and
>> >> >> > DEVICE_OBJECT' s NextDevice fields are your friends here), and
>> >> >> > call
>> >> >> > IoGetLowerDeviceObject() for every DEVICE_OBJECT . If the call
>> >> >> > is
>> >> >> > sucessfull,
>> >> >> > it means that the target DEVICE_OBJECT just cannot be a PDO, for
>> >> >> > understandable reasons. This is how you can get the list of all
>> >> >> > PDO's
>> >> >> > that
>> >> >> > driver has created....
>> >> >> >
>> >> >>
>> >> >> The above method works fine until the system jumps in and adds or
>> >> >> deletes
>> >> >> a
>> >> >> DEVICE_OBJECT from the list, since the lock to control this is
>> >> >> totally
>> >> >> buried you are creating a crash that is going to happen sooner or
>> >> >> later.
>> >> >>
>> >> >>
>> >> >> --
>> >> >> 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
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>