Hi All,
Is there any know limitation, consideration when implementing mini-filter driver, that should be considered because of NTFS EFS? Because when my filter driver come across with EncryptFile, DecryptFile Win32 api functions, some strange things starts to happening(low performance, os become unresponsive, …). Filter is somekind of file changes spy…
Br, Mitja
Nothing I can think of in particular to this case other than I hope you
handling files that are smaller than 1kb correctly.
Perhaps other members of this list will assist you in generating a dump
when the hang occurs. There is a tool out there
MS distributes that will allow certain keyboard press generated a dump,
but I can’t think of what it’s called at the moment.
If you can get a dump of when the hang occurs, I’d figure looking at
what is holding a lock might be of use.
Matt
xxxxx@hermes-softlab.com wrote:
Hi All,
Is there any know limitation, consideration when implementing mini-filter driver, that should be considered because of NTFS EFS? Because when my filter driver come across with EncryptFile, DecryptFile Win32 api functions, some strange things starts to happening(low performance, os become unresponsive, …). Filter is somekind of file changes spy…
Br, Mitja
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminarsYou are currently subscribed to ntfsd as: matt-martin@tx.rr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Hi Mitja,
The thing to keep in mind with minifilters is that the filter manager has absolutely no linear qualities about it. Over and over again, inside my own preop and postop functions, I saw functions being called before the last call to the same function was even 3 or 4 lines into the function. EVERYTHING is asynchronous. If you try to synchronize, it’s going to be a knock-down, drag-out battle to the death with the filter manager. I ended up having to dump all but the most basic functionality out of the driver and into the companion .DLL. You cannot stop the overlapping calls. I used fast mutexes and they helped but they still could not stabilize the rampant disorganization of the filter manager. It rolls through your drivers like a blind battleship doing 100 knots. I tried multithreading to handle the logging - anomalies were so rampant that I had to eliminate the entire concept. You can pause the filter manager but then crashes galore happen. I tried deferring calls; that didn’t help either. More anomalies. A driver that shouldn’t have taken 50 hours required over 1000 just to stabilize it. All it did was log changes to disk files; collect old data on the pre-write and log new data on post-write. Nothing too difficult but that thing was out for blood. It was all because of timing. If I delayed the filter manager by any perceivable amount, it was nothing but anomalies. I’ve done VxD’s, DOS drivers, BIOS functions, ATA / PCI direct interfacing, and massive QIC / floppy work since 1984. I never saw anything like this filter manager. Not even close. I have never, ever had half the problems I had here - even the QIC drivers, which were so complex, only two existed on the market at the time I wrote mine - were not half this difficult.
The only thing I could find that worked was to make the driver’s presence as light as possible. It collects data and buffers it into memory; the companion DLL retrieves that data as fast as inhumanly possible. Nothing else could be done inside the driver. It wouldn’t stabilize.
You will never find a logical reason for most of the crashes you encounter. Don’t kill yourself looking for them.
Date: Thu, 20 Dec 2007 10:22:30 -0500> From: xxxxx@hermes-softlab.com> To: xxxxx@lists.osr.com> Subject: [ntfsd] Problems with EncryptFile, DecryptFile with mini-filter> > Hi All,> > Is there any know limitation, consideration when implementing mini-filter driver, that should be considered because of NTFS EFS? Because when my filter driver come across with EncryptFile, DecryptFile Win32 api functions, some strange things starts to happening(low performance, os become unresponsive, …). Filter is somekind of file changes spy…> > Br, Mitja> > > —> NTFSD is sponsored by OSR> > For our schedule debugging and file system seminars> (including our new fs mini-filter seminar) visit: > http://www.osr.com/seminars\> > You are currently subscribed to ntfsd as: xxxxx@msn.com> To unsubscribe send a blank email to xxxxx@lists.osr.com
i?m is proud to present Cause Effect, a series about real people making a difference.
http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect
You don’t even need a special tool, there’s a registry setting. The key
sequence is [ctrl][scroll lock][scroll lock] (hold control, tap scroll
lock twice). If you google that along with “crash windows”, it’ll
probably get you the registry key and other info you need. Alternately,
in windbg or kd, run .crash. Or you could just break in with the
debugger if you don’t need to save it for posterity.
~Eric
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of MM
Sent: Thursday, December 20, 2007 10:34 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Problems with EncryptFile, DecryptFile with
mini-filter
Nothing I can think of in particular to this case other than I hope you
handling files that are smaller than 1kb correctly.
Perhaps other members of this list will assist you in generating a dump
when the hang occurs. There is a tool out there MS distributes that will
allow certain keyboard press generated a dump, but I can’t think of what
it’s called at the moment.
If you can get a dump of when the hang occurs, I’d figure looking at
what is holding a lock might be of use.
Matt
xxxxx@hermes-softlab.com wrote:
Hi All,
Is there any know limitation, consideration when implementing
mini-filter driver, that should be considered because of NTFS EFS?
Because when my filter driver come across with EncryptFile, DecryptFile
Win32 api functions, some strange things starts to happening(low
performance, os become unresponsive, …). Filter is somekind of file
changes spy…Br, Mitja
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminarsYou are currently subscribed to ntfsd as: matt-martin@tx.rr.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
Sorry there is no such thing a 50 hour file system driver. I tell most
customers to expect a minimum of 500 hours for something in the file system
stack. Your statements show a fundamental lack of understanding of how
Windows and the storage stack work. Everything in the kernel is highly
asynchronous. Your problems reflect not understanding the rules of kernel
programming, and the realities of dealing with multi-threaded systems.
I have my problems with the filter manager (see the “What are the
limitations of Minifilter” thread) but do not condem the filter manager this
is the nature of the Windows kernel. You can synchronize things, but there
are limits which you have to understand plan for before writing a line of
code. Don’t blame the tool for your lack of preparation.
–
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
“Chris Malcheski” wrote in message news:xxxxx@ntfsd…
Hi Mitja,
The thing to keep in mind with minifilters is that the filter manager has
absolutely no linear qualities about it. Over and over again, inside my own
preop and postop functions, I saw functions being called before the last
call to the same function was even 3 or 4 lines into the function.
EVERYTHING is asynchronous. If you try to synchronize, it’s going to be a
knock-down, drag-out battle to the death with the filter manager. I ended
up having to dump all but the most basic functionality out of the driver and
into the companion .DLL. You cannot stop the overlapping calls. I used
fast mutexes and they helped but they still could not stabilize the rampant
disorganization of the filter manager. It rolls through your drivers like a
blind battleship doing 100 knots. I tried multithreading to handle the
logging - anomalies were so rampant that I had to eliminate the entire
concept. You can pause the filter manager but then crashes galore happen.
I tried deferring calls; that didn’t help either. More anomalies. A driver
that shouldn’t have taken 50 hours required over 1000 just to stabilize it.
All it did was log changes to disk files; collect old data on the pre-write
and log new data on post-write. Nothing too difficult but that thing was
out for blood. It was all because of timing. If I delayed the filter
manager by any perceivable amount, it was nothing but anomalies. I’ve done
VxD’s, DOS drivers, BIOS functions, ATA / PCI direct interfacing, and
massive QIC / floppy work since 1984. I never saw anything like this filter
manager. Not even close. I have never, ever had half the problems I had
here - even the QIC drivers, which were so complex, only two existed on the
market at the time I wrote mine - were not half this difficult.
The only thing I could find that worked was to make the driver’s presence as
light as possible. It collects data and buffers it into memory; the
companion DLL retrieves that data as fast as inhumanly possible. Nothing
else could be done inside the driver. It wouldn’t stabilize.
You will never find a logical reason for most of the crashes you encounter.
Don’t kill yourself looking for them.
> Date: Thu, 20 Dec 2007 10:22:30 -0500> From:
> xxxxx@hermes-softlab.com> To: xxxxx@lists.osr.com> Subject: [ntfsd]
> Problems with EncryptFile, DecryptFile with mini-filter> > Hi All,> > Is
> there any know limitation, consideration when implementing mini-filter
> driver, that should be considered because of NTFS EFS? Because when my
> filter driver come across with EncryptFile, DecryptFile Win32 api
> functions, some strange things starts to happening(low performance, os
> become unresponsive, …). Filter is somekind of file changes spy…> >
> Br, Mitja> > > —> NTFSD is sponsored by OSR> > For our schedule
> debugging and file system seminars> (including our new fs mini-filter
> seminar) visit: > http://www.osr.com/seminars> > You are currently
> subscribed to ntfsd as: xxxxx@msn.com> To unsubscribe send a blank
> email to xxxxx@lists.osr.com
_________________________________________________________________
i’m is proud to present Cause Effect, a series about real people making a
difference.
http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect
Well, I guess it’s time for bed 
I’ve never personally used this functionality, I’ve always had a
debugger connected when things
went unexpected (or shall I say, ‘as expected’) .
I’m not thinking of the ‘bang’ tool, there is another out there if I
recall correctly, but then again I
can’t think right now… Perhaps on older systems there was a separate
tool in the ddk for this,
I’m unsure at this point.
Matt
Eric Diven wrote:
You don’t even need a special tool, there’s a registry setting. The key
sequence is [ctrl][scroll lock][scroll lock] (hold control, tap scroll
lock twice). If you google that along with “crash windows”, it’ll
probably get you the registry key and other info you need. Alternately,
in windbg or kd, run .crash. Or you could just break in with the
debugger if you don’t need to save it for posterity.~Eric
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of MM
Sent: Thursday, December 20, 2007 10:34 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Problems with EncryptFile, DecryptFile with
mini-filterNothing I can think of in particular to this case other than I hope you
handling files that are smaller than 1kb correctly.Perhaps other members of this list will assist you in generating a dump
when the hang occurs. There is a tool out there MS distributes that will
allow certain keyboard press generated a dump, but I can’t think of what
it’s called at the moment.If you can get a dump of when the hang occurs, I’d figure looking at
what is holding a lock might be of use.Matt
xxxxx@hermes-softlab.com wrote:
>Hi All,
>
>Is there any know limitation, consideration when implementing
>
>
mini-filter driver, that should be considered because of NTFS EFS?
Because when my filter driver come across with EncryptFile, DecryptFile
Win32 api functions, some strange things starts to happening(low
performance, os become unresponsive, …). Filter is somekind of file
changes spy…>Br, Mitja
>
>
>—
>NTFSD is sponsored by OSR
>
>For our schedule debugging and file system seminars (including our new
>fs mini-filter seminar) visit:
>http://www.osr.com/seminars
>
>You are currently subscribed to ntfsd as: matt-martin@tx.rr.com To
>unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
>
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminarsYou are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminarsYou are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
> You will never find a logical reason for most of the crashes you
encounter. Don’t kill yourself looking for them.
Sorry, but this is not only bunk but really bad advice. Filters and FSDs
(and most device drivers) are complex pieces of software within a complex
system, so, yes, the crashes/hangs/corruptions you encounter can be
incredibly difficult to analyze. However, that just comes with the territory
here and you can’t simply ignore them (I don’t know about you, but our
customers just hate it when they lose their data. Picky, picky…). You
*need* to find a logical reason for these things, otherwise you’re fooling
yourself in thinking that you truly understand the environment under which
your driver is running.
The good news is that the ability to analyze these issues is a learned
skill, it just takes time, effort, and practice. So, instead of advising
people to just give up and ignore the anamolous behavior they see, I’d
advise them to not get discouraged. I’d advise them to spend as much time as
possible learning about general O/S concepts, Windows internals, the x86/x64
platforms, and their specific technology. Then, when they get a crash or a
hang, they can apply all of this knowledge methodically and try to
hypothesize (i.e. guess) a logical reason for it. Then they collect
information to support or refute that conclusion. Rinse and repeat until
they uncover the core issue or stop making progress, at which point it’s
time to shelf it to come back to later or simply ask for help (it’s
absolutely amazing what a fresh set of eyes can do). This is the *only* way
to gain the skills necessary to perform this (critical) part of the job.
-scott
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Chris Malcheski” wrote in message news:xxxxx@ntfsd…
Hi Mitja,
The thing to keep in mind with minifilters is that the filter manager has
absolutely no linear qualities about it. Over and over again, inside my own
preop and postop functions, I saw functions being called before the last
call to the same function was even 3 or 4 lines into the function.
EVERYTHING is asynchronous. If you try to synchronize, it’s going to be a
knock-down, drag-out battle to the death with the filter manager. I ended
up having to dump all but the most basic functionality out of the driver and
into the companion .DLL. You cannot stop the overlapping calls. I used
fast mutexes and they helped but they still could not stabilize the rampant
disorganization of the filter manager. It rolls through your drivers like a
blind battleship doing 100 knots. I tried multithreading to handle the
logging - anomalies were so rampant that I had to eliminate the entire
concept. You can pause the filter manager but then crashes galore happen.
I tried deferring calls; that didn’t help either. More anomalies. A driver
that shouldn’t have taken 50 hours required over 1000 just to stabilize it.
All it did was log changes to disk files; collect old data on the pre-write
and log new data on post-write. Nothing too difficult but that thing was
out for blood. It was all because of timing. If I delayed the filter
manager by any perceivable amount, it was nothing but anomalies. I’ve done
VxD’s, DOS drivers, BIOS functions, ATA / PCI direct interfacing, and
massive QIC / floppy work since 1984. I never saw anything like this filter
manager. Not even close. I have never, ever had half the problems I had
here - even the QIC drivers, which were so complex, only two existed on the
market at the time I wrote mine - were not half this difficult.
The only thing I could find that worked was to make the driver’s presence as
light as possible. It collects data and buffers it into memory; the
companion DLL retrieves that data as fast as inhumanly possible. Nothing
else could be done inside the driver. It wouldn’t stabilize.
You will never find a logical reason for most of the crashes you encounter.
Don’t kill yourself looking for them.
> Date: Thu, 20 Dec 2007 10:22:30 -0500
> From: xxxxx@hermes-softlab.com
> To: xxxxx@lists.osr.com
> Subject: [ntfsd] Problems with EncryptFile, DecryptFile with mini-filter
>
> Hi All,
>
> Is there any know limitation, consideration when implementing mini-filter
> driver, that should be considered because of NTFS EFS? Because when my
> filter driver come across with EncryptFile, DecryptFile Win32 api
> functions, some strange things starts to happening(low performance, os
> become unresponsive, …). Filter is somekind of file changes spy…
>
> Br, Mitja
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@msn.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
i’m is proud to present Cause Effect, a series about real people making a
difference. Learn more
Tnx for a set discouraging and not so discouraging advices, but everything you guys said does not help me I would like just some advice, tip about NTFS EFS in cooperation with mini-filter drivers, or maybe link to additional documentation which covers this … But anyway tnx …
Br, Mitja
Buy source code access to Windows and you can find the answer. Otherwise,
it is an undocumented implementation. No documentation at all since the
only book was written before EFS was implemented. Read all the user
functions that can be used with encrypted files. Look especially at the
backup options. Write your own program or use the free test program you can
find on OSR. Trap in your driver and see how all requests are processed.
There is a user mode component in the MS implementation. Windbg is free and
your friend. You may have several weeks of work ahead of you.
wrote in message news:xxxxx@ntfsd…
> Tnx for a set discouraging and not so discouraging advices, but
> everything you guys said does not help me I would like just some
> advice, tip about NTFS EFS in cooperation with mini-filter drivers, or
> maybe link to additional documentation which covers this … But anyway
> tnx …
> Br, Mitja
>
>
Just a few comments in line:
xxxxx@hermes-softlab.com wrote:
but everything you guys said does not help me
Supposedly, Benjamin Franklin once said, “God helps those who help
themselves”. This is your opportunity
to increase your knowledge of WinDbg while at the same time gaining
valuable skills ($). If you can
force a dump during the hang, people here will be happy to assist you in
analyzing it, from viewing held locks
to locating the threads that are hanging and why.
I would like just some advice, tip about NTFS EFS in cooperation with mini-filter drivers, or maybe link to additional documentation which covers this … But anyway tnx …
Sorry, there are no links of the sort. The best you could do would be
search the archives - however, in your case I don’t that would help
a lot but it is always worth a try. Other than what is contained in the
OSR archives, to my knowledge there has NEVER been a single
paper or any ddk/wdk documentation written on encryption drivers in any
capacity. (Publicly available I mean)
The easiest thing to do would be to follow these instructions and
analyze a dump with WinDbg:
http://support.microsoft.com/kb/244139
Good Luck,
Matt
Br, Mitja
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminarsYou are currently subscribed to ntfsd as: matt-martin@tx.rr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Hi,
Marc Russinovich wrote extensively about EFS implementation back in 99 and
in the 4th edition of windows internal book.
Interestingly MS didn’t choose a filter model for their architecture at the
time.
Jerome.
“MM” wrote in message news:xxxxx@ntfsd…
> Just a few comments in line:
>
> xxxxx@hermes-softlab.com wrote:
>
> >but everything you guys said does not help me
> >
> Supposedly, Benjamin Franklin once said, “God helps those who help
> themselves”. This is your opportunity
> to increase your knowledge of WinDbg while at the same time gaining
> valuable skills ($). If you can
> force a dump during the hang, people here will be happy to assist you in
> analyzing it, from viewing held locks
> to locating the threads that are hanging and why.
>
> >I would like just some advice, tip about NTFS EFS in cooperation with
mini-filter drivers, or maybe link to additional documentation which covers
this … But anyway tnx …
> >
> >
> Sorry, there are no links of the sort. The best you could do would be
> search the archives - however, in your case I don’t that would help
> a lot but it is always worth a try. Other than what is contained in the
> OSR archives, to my knowledge there has NEVER been a single
> paper or any ddk/wdk documentation written on encryption drivers in any
> capacity. (Publicly available I mean)
>
> The easiest thing to do would be to follow these instructions and
> analyze a dump with WinDbg:
>
> http://support.microsoft.com/kb/244139
>
> Good Luck,
>
> Matt
>
> >Br, Mitja
> >
> >
> >—
> >NTFSD is sponsored by OSR
> >
> >For our schedule debugging and file system seminars
> >(including our new fs mini-filter seminar) visit:
> >http://www.osr.com/seminars
> >
> >You are currently subscribed to ntfsd as: matt-martin@tx.rr.com
> >To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
>
Well thanks for the tip, I’ll try to look that up - even though I don’t
know how relevant the information
would still be… Given the time to write and publish a book, and if
was indeed in '99 as you say, that
info is over 10 years old… but I’d still love to read it!
The 4th edition of that book couldn’t of been that long
ago… How sure are you about that?
Regards,
Matthew
Ps. Are you talking about two different litatures? If so, what is the first?
jchristatos wrote:
Hi,
Marc Russinovich wrote extensively about EFS implementation back in 99 and
in the 4th edition of windows internal book.
Interestingly MS didn’t choose a filter model for their architecture at the
time.Jerome.
“MM” wrote in message news:xxxxx@ntfsd…
>
>
>>Just a few comments in line:
>>
>>xxxxx@hermes-softlab.com wrote:
>>
>>
>>
>>>but everything you guys said does not help me
>>>
>>>
>>>
>>Supposedly, Benjamin Franklin once said, “God helps those who help
>>themselves”. This is your opportunity
>>to increase your knowledge of WinDbg while at the same time gaining
>>valuable skills ($). If you can
>>force a dump during the hang, people here will be happy to assist you in
>>analyzing it, from viewing held locks
>>to locating the threads that are hanging and why.
>>
>>
>>
>>>I would like just some advice, tip about NTFS EFS in cooperation with
>>>
>>>
>mini-filter drivers, or maybe link to additional documentation which covers
>this … But anyway tnx …
>
>
>>>
>>>
>>Sorry, there are no links of the sort. The best you could do would be
>>search the archives - however, in your case I don’t that would help
>>a lot but it is always worth a try. Other than what is contained in the
>>OSR archives, to my knowledge there has NEVER been a single
>>paper or any ddk/wdk documentation written on encryption drivers in any
>>capacity. (Publicly available I mean)
>>
>>The easiest thing to do would be to follow these instructions and
>>analyze a dump with WinDbg:
>>
>>http://support.microsoft.com/kb/244139
>>
>>Good Luck,
>>
>>Matt
>>
>>
>>
>>>Br, Mitja
>>>
>>>
>>>—
>>>NTFSD is sponsored by OSR
>>>
>>>For our schedule debugging and file system seminars
>>>(including our new fs mini-filter seminar) visit:
>>>http://www.osr.com/seminars
>>>
>>>You are currently subscribed to ntfsd as: matt-martin@tx.rr.com
>>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>>
>>>
>>>
>>>
>>>
>
>
>
>—
>NTFSD is sponsored by OSR
>
>For our schedule debugging and file system seminars
>(including our new fs mini-filter seminar) visit:
>http://www.osr.com/seminars
>
>You are currently subscribed to ntfsd as: matt-martin@tx.rr.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
“MM” wrote in message news:xxxxx@ntfsd…
> Well thanks for the tip, I’ll try to look that up - even though I don’t
> know how relevant the information
> would still be… Given the time to write and publish a book, and if
> was indeed in '99 as you say, that
> info is over 10 years old… but I’d still love to read it!
“Inside EFS” was pusblished by winntmag at the time and was available at the
sysinternal site.
>
> The 4th edition of that book couldn’t of been that long
> ago… How sure are you about that?
I just opened my copy of the book 
Yes, There is lot of inertia in this field.
(wasn’t Vista net layer bitten by a 10yrs dpc/isr latency pb?)
Jerome.
>
> Regards,
>
> Matthew
>
> Ps. Are you talking about two different litatures? If so, what is the
first?
>
> jchristatos wrote:
>
> >Hi,
> >
> >Marc Russinovich wrote extensively about EFS implementation back in 99
and
> >in the 4th edition of windows internal book.
> >Interestingly MS didn’t choose a filter model for their architecture at
the
> >time.
> >
> >Jerome.
> >
> >“MM” wrote in message news:xxxxx@ntfsd…
> >
> >
> >>Just a few comments in line:
> >>
> >>xxxxx@hermes-softlab.com wrote:
> >>
> >>
> >>
> >>>but everything you guys said does not help me
> >>>
> >>>
> >>>
> >>Supposedly, Benjamin Franklin once said, “God helps those who help
> >>themselves”. This is your opportunity
> >>to increase your knowledge of WinDbg while at the same time gaining
> >>valuable skills ($). If you can
> >>force a dump during the hang, people here will be happy to assist you in
> >>analyzing it, from viewing held locks
> >>to locating the threads that are hanging and why.
> >>
> >>
> >>
> >>>I would like just some advice, tip about NTFS EFS in cooperation with
> >>>
> >>>
> >mini-filter drivers, or maybe link to additional documentation which
covers
> >this … But anyway tnx …
> >
> >
> >>>
> >>>
> >>Sorry, there are no links of the sort. The best you could do would be
> >>search the archives - however, in your case I don’t that would help
> >>a lot but it is always worth a try. Other than what is contained in the
> >>OSR archives, to my knowledge there has NEVER been a single
> >>paper or any ddk/wdk documentation written on encryption drivers in any
> >>capacity. (Publicly available I mean)
> >>
> >>The easiest thing to do would be to follow these instructions and
> >>analyze a dump with WinDbg:
> >>
> >>http://support.microsoft.com/kb/244139
> >>
> >>Good Luck,
> >>
> >>Matt
> >>
> >>
> >>
> >>>Br, Mitja
> >>>
> >>>
> >>>—
> >>>NTFSD is sponsored by OSR
> >>>
> >>>For our schedule debugging and file system seminars
> >>>(including our new fs mini-filter seminar) visit:
> >>>http://www.osr.com/seminars
> >>>
> >>>You are currently subscribed to ntfsd as: matt-martin@tx.rr.com
> >>>To unsubscribe send a blank email to xxxxx@lists.osr.com
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >—
> >NTFSD is sponsored by OSR
> >
> >For our schedule debugging and file system seminars
> >(including our new fs mini-filter seminar) visit:
> >http://www.osr.com/seminars
> >
> >You are currently subscribed to ntfsd as: matt-martin@tx.rr.com
> >To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
>