When I use Walter Oney’s AppWizard, I generate the source
code using Visual C++ 6.0, then write a sources file and
compile the program separately using the DDK build
environment at the command line.
Scott
— Windows System Software Devs Interest List digest
$B$+$i$N%a%C%;!<%8!'(B
> NTDEV Digest for Thursday, July 21, 2005.
>
> 1. Re: ZwOpenFile never return
> 2. Re: About timer in miniport driver !
> 3. Compiler version not supported by Windows DDK.
> 4. USBD_PIPE_INFORMATION
> 5. USB client driver (sending and receiving data)
> 6. IoCallDriver
> 7. Re: Common Buffer + numberofmapregisters
> 8. Re: WinXP will clear debug register
> automatically?
> 9. RE: WinXP will clear debug register
> automatically?
> 10. Re: Compiler version not supported by Windows
> DDK.
> 11. Re: WinXP will clear debug register
> automatically?
> 12. Re: WinXP will clear debug register
> automatically?
> 13. RE: Common Buffer + numberofmapregisters
> 14. Re: Compiler version not supported by Windows
> DDK.
> 15. Video driver display rotation
> 16. Re: Compiler version not supported by Windows
> DDK.
> 17. Printer Driver Problem:Partial Image
> 18. Re: Where do I find Microsoft’s gexport.exe
> sample?
> 19. Re: Compiler version not supported by Windows
> DDK.
> 20. Re: USBD_PIPE_INFORMATION
> 21. Re: USB client driver (sending and receiving
> data)
> 22. Re: Re:Compiler version not supported by Windows
> DDK.
> 23. Re: Compiler version not supported by Windows
> DDK.
> 24. Re: Compiler version not supported by Windows
> DDK.
> 25. RE: USBD_PIPE_INFORMATION
> 26. RE: IoCallDriver
> 27. Re: Compiler version not supported by Windows
> DDK.
> 28. Re: IRP_MJ_CLEANUP is not called
> 29. Re: Where do I find Microsoft’s gexport.exe
> sample?
> 30. Re: About timer in miniport driver !
> 31. Re:pnp scsi miniport not calling hwFindAdapter
> 32. RE: pnp scsi miniport not calling hwFindAdapter
> 33. RE: pnp scsi miniport not calling hwFindAdapter
> 34. Re: Where do I find Microsoft’s gexport.exe
> sample?
> 35. Re: Re:pnp scsi miniport not calling
> hwFindAdapter
> 36. Re: IRP_MJ_CLEANUP is not called
> 37. Re: IoCallDriver
> 38. Re:Re:pnp scsi miniport not calling
> hwFindAdapter
> 39. Re: Re:Compiler version not supported by Windows
> DDK.
> 40. How to make FS display the disk block level
> change
> 41. RE: How to make FS display the disk block level
> change
> 42. Re: How to make FS display the disk block level
> change
>
>
----------------------------------------------------------------------
>
> Subject: Re: ZwOpenFile never return
> From: “Slava Imameyev”
> Date: Thu, 21 Jul 2005 11:06:25 +0400
> X-Message-Number: 1
>
> Possibly may induce deadlock.
> To check this- do not block, send open request to
> other thread and then( not
> waiting reply from ZwOpenFile ) send Irp to
> partition driver.
>
> “Xu Ge” wrote in message
> news:xxxxx@ntdev…
> >i only block the read write irp sended to
> HarddiskVolume1, but ZwOpenFile
> > i called is for HarddiskVolume2, can this induce
> the deadlock ?
> >
> > my driver is a partition upper filter driver.
> >
> > “Slava Imameyev”
> $BP4Hk!&O"PBNE(B:xxxxx@ntdev…
> >> First of all, I think your debugger uses wrong
> symbols.
> >> The following is only my guess.
> >> If you catch IRP under file system driver( your
> filter is upper for
> >> disk/partition driver ) and block it( block IRP
> sending to disk/partition
> >> driver) waiting while ZwOpenFile returns you may
> block ZwOpenFile
> >> because ZwOpenFile calls file system driver and
> this file system driver
> >> tries to acquire resources which already has been
> acquired in thread that
> >> you block. I guess you create dead lock - you
> waiting in thread that
> >> acquired exclusive resource before you call
> ZwOpenFile, and this other
> >> thread also try to acquire the same resource
> exclusive.
> >> If you use file system upper filter or do not
> block thread my guess is
> >> wrong.
> >>
> >> “Xu Ge” wrote in
> message news:xxxxx@ntdev…
> >>> yes, the IRQL == PASSIVE_LEVEL, i call
> ZwOpenFile in a system thread and
> >>> never raise irql,
> >>>
> >>> when i use windbg to analyze the lock, the cmd
> output’s like this:
> >>> (my driver is backupex, the thread startup proc
> is FilterThread)
> >>>
> >>>
>
==================================================================
> >>> kd> !locks
> >>> DUMP OF ALL RESOURCE OBJECTS
> >>> KD: Scanning for held locks…
> >>>
> >>> Resource @ 0x814824f4 Exclusively owned
> >>> Contention Count = 2
> >>> NumberOfSharedWaiters = 1
> >>> Threads: 81473760-02<> 8144f900-01
> >>> KD: Scanning for held locks.
> >>>
> >>> Resource @ 0x81462368 Exclusively owned
> >>> Threads: 81473760-01<>
> >>> KD: Scanning for held locks.
> >>>
> >>> Resource @ 0x813f66e8 Exclusively owned
> >>> Threads: 81473760-01<>
> >>> KD: Scanning for held locks.
> >>>
> >>> Resource @ 0x8146ef40 Shared 1 owning threads
> >>> Threads: 81472623-01<> *** Actual Thread
> 81472620
> >>> KD: Scanning for held locks…
> >>> 229 total locks, 4 locks currently held
> >>> kd> !locks -v 814824f4
> >>>
> >>> Resource @ 0x814824f4 Exclusively owned
> >>> Contention Count = 2
> >>> NumberOfSharedWaiters = 1
> >>> Threads: 81473760-02<*>
> >>>
> >>> THREAD 81473760 Cid 8.4 Teb: 00000000
> Win32Thread: 00000000 WAIT:
> >>> (Executive) KernelMode Non-Alertable
> >>> f7422b98 NotificationEvent
> >>> IRP List:
> >>> 813ace68: (0006,0190) Flags: 00000884
> Mdl: 00000000
> >>> 814543e8: (0006,0094) Flags: 00000000
> Mdl: 00000000
> >>> Not impersonating
> >>> Owning Process 814739e0
> >>> Wait Start TickCount 863
> Elapsed Ticks: 5774
> >>> Context Switch Count 770
> >>> UserTime 0:00:00.0000
> >>> KernelTime 0:00:06.0937
> >>> Start Address nt!IoWMISuggestInstanceName
> (0x8054aca6)
> >>> Stack Init f7424000 Current f74226c0 Base
> f7424000 Limit f7421000
> >>> Call 0
> >>> Priority 31 BasePriority 8 PriorityDecrement
> 0 DecrementCount 0
> >>>
> >>> ChildEBP RetAddr Args to Child
> >>> f7422700 bfedf6d6 f7422b98 00000000 00000000
> nt!RtlMoveMemory+0x136d
> >>> f74228d0 bfee1598 81462d28 81451148 813f6e08
> Ntfs+0x16d6
> >>> f7422c58 bfee1dc2 81462d28 81451148 00000000
> Ntfs+0x3598
> >>> f7422cc4 8041f54b 81482020 81451148 813f6cf8
> Ntfs+0x3dc2
> >>> f7422cec 8043bd9d 813f6cf8 f7422d14 f7422d94
>
> >>> nt!IoBuildSynchronousFsdRequest+0x8f
> >>> f7422dac 8043ba52 e14c2040 e14c2044 00000019
>
> >>> nt!MmDisableModifiedWriteOfSection+0x914
> >>> f7422de8 80410f39 813f6dd4 e14c2040 00001000
>
> >>> nt!MmDisableModifiedWriteOfSection+0x5c9
> >>> f7422eac bff15345 813f6dd4 f7422f48 00001000
> nt!CcFlushCache+0x353
>
=== message truncated ===
__________________________________
Save the earth
http://pr.mail.yahoo.co.jp/ondanka/