Hi,
I have built the passthrough mini filter driver that came with IFS kit under windows 2000 build environment. I have installed the driver and trying to load it through the command on windows 2000 server machine,
“fltmc load passThrough”. I get the following error,
Load failed with error: 0x8007007f
The specified procedure could not be found.
I have applied the SP4 patch and also Rollup 1 for windows 2000 sp4. I’m very new to developing drivers on windows. Can some one help me regarding this???
My windows machine version : Windows 2000, build 2195, service pack 4.
Thanks.
> Load failed with error: 0x8007007f
The specified procedure could not be found.
Run Depends.exe YourDriver.sys. You will see what’s
missing there.
L.
Thanks a lot. That was my first post and felt happy to see very quick response.
I got it. I have added Registry callback functions (CmRegisterCallback()) in this filter and was trying to load on windows 2000 which are not exported by NTOSKRNL.EXE on windows 2000 SP4. I commented them now, and its working fine.
Can we use these registry callback functions on windows 2000. wat patches that need to be applied to support these functions on win2000??? I’m at windows 2004 SP4.
Any ways, thanks a lot.
No, CmRegisterCallback was XP or later. Unfortunately the only approach for
Windows 2000 is hooking. Use MmGetSystemRoutineAddress to get a pointer to
CmRegisterCallback if present, or otherwise have your own hooking function
to get the callbacks.
–
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
wrote in message news:xxxxx@ntfsd…
> Thanks a lot. That was my first post and felt happy to see very quick
> response.
>
> I got it. I have added Registry callback functions (CmRegisterCallback())
> in this filter and was trying to load on windows 2000 which are not
> exported by NTOSKRNL.EXE on windows 2000 SP4. I commented them now, and
> its working fine.
>
> Can we use these registry callback functions on windows 2000. wat patches
> that need to be applied to support these functions on win2000??? I’m at
> windows 2004 SP4.
>
> Any ways, thanks a lot.
>
It’s my understanding that there is a memory (or handle) leak in the
registry callback stuff on XP. I think it was fixed in Server 2003 SP1.
Also, if you look at the Argument1 values (RegNtPreSetValueKey etc.)
for the callback on XP, Server 2003 and Vista, you’ll note a lot of
little differences.
Given the two, I hook on W2K & XP and ‘go by the book’ on Vista. (I
don’t need to support Server.)
Mickey.
Don Burn wrote:
No, CmRegisterCallback was XP or later. Unfortunately the only approach for
Windows 2000 is hooking. Use MmGetSystemRoutineAddress to get a pointer to
CmRegisterCallback if present, or otherwise have your own hooking function
to get the callbacks.
Don, “CmRegisterCallback” is alphatecially placed under the first HAL export
“HalAcquireDisplayOwnership” which means it is subject to the
MmGetSystemRoutineAddress bug which bluescreens a system on Win2000 and XP
(below SP3).
//Daniel
“Don Burn” wrote in message news:xxxxx@ntfsd…
> No, CmRegisterCallback was XP or later. Unfortunately the only approach
> for Windows 2000 is hooking. Use MmGetSystemRoutineAddress to get a
> pointer to CmRegisterCallback if present, or otherwise have your own
> hooking function to get the callbacks.
>
>
> –
> 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
>
>
>
>
> wrote in message news:xxxxx@ntfsd…
>> Thanks a lot. That was my first post and felt happy to see very quick
>> response.
>>
>> I got it. I have added Registry callback functions (CmRegisterCallback())
>> in this filter and was trying to load on windows 2000 which are not
>> exported by NTOSKRNL.EXE on windows 2000 SP4. I commented them now, and
>> its working fine.
>>
>> Can we use these registry callback functions on windows 2000. wat patches
>> that need to be applied to support these functions on win2000??? I’m at
>> windows 2004 SP4.
>>
>> Any ways, thanks a lot.
>>
>
>
>
Oops. shows I have not been there in a while. Thanks for the heads up.
Wish Microsoft would stop adding “features” and start fixing bugs.
–
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
wrote in message news:xxxxx@ntfsd…
> Don, “CmRegisterCallback” is alphatecially placed under the first HAL
> export “HalAcquireDisplayOwnership” which means it is subject to the
> MmGetSystemRoutineAddress bug which bluescreens a system on Win2000 and XP
> (below SP3).
>
> //Daniel
>
>
> “Don Burn” wrote in message news:xxxxx@ntfsd…
>> No, CmRegisterCallback was XP or later. Unfortunately the only approach
>> for Windows 2000 is hooking. Use MmGetSystemRoutineAddress to get a
>> pointer to CmRegisterCallback if present, or otherwise have your own
>> hooking function to get the callbacks.
>>
>>
>> –
>> 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
>>
>>
>>
>>
>> wrote in message news:xxxxx@ntfsd…
>>> Thanks a lot. That was my first post and felt happy to see very quick
>>> response.
>>>
>>> I got it. I have added Registry callback functions
>>> (CmRegisterCallback()) in this filter and was trying to load on windows
>>> 2000 which are not exported by NTOSKRNL.EXE on windows 2000 SP4. I
>>> commented them now, and its working fine.
>>>
>>> Can we use these registry callback functions on windows 2000. wat
>>> patches that need to be applied to support these functions on win2000???
>>> I’m at windows 2004 SP4.
>>>
>>> Any ways, thanks a lot.
>>>
>>
>>
>>
>
>
If you go this way, I have a nice hook quality testing tool which checks if
you probe and protect the user mode parameters properly in your hooks. It’s
something in the style of Sysinternals NtCrash which was unfortunately
retracted by MS after they took over Sysinternals.
Here it is: http://www.resplendence.com/hookanalyzer
you need to run it with the /hooktest command line switch to have this
functionality enabled.
//Daniel
“Mickey Lane” wrote in message news:xxxxx@ntfsd…
> It’s my understanding that there is a memory (or handle) leak in the
> registry callback stuff on XP. I think it was fixed in Server 2003 SP1.
>
> Also, if you look at the Argument1 values (RegNtPreSetValueKey etc.)
> for the callback on XP, Server 2003 and Vista, you’ll note a lot of
> little differences.
>
> Given the two, I hook on W2K & XP and ‘go by the book’ on Vista. (I
> don’t need to support Server.)
>
> Mickey.
>
> Don Burn wrote:
>> No, CmRegisterCallback was XP or later. Unfortunately the only approach
>> for Windows 2000 is hooking. Use MmGetSystemRoutineAddress to get a
>> pointer to CmRegisterCallback if present, or otherwise have your own
>> hooking function to get the callbacks.
>>
>>
>
Daniel,
Nice. It didn’t uncover any problems in Windows 2000 running under
VMware with or without the /hooktest switch.
Are there any public code samples that show how to equate the observed
hook address to the driver and its provider?
Thanks for the pointer,
Mickey.
xxxxx@resplendence.com wrote:
If you go this way, I have a nice hook quality testing tool which checks
if you probe and protect the user mode parameters properly in your
hooks. It’s something in the style of Sysinternals NtCrash which was
unfortunately retracted by MS after they took over Sysinternals.
Here it is: http://www.resplendence.com/hookanalyzer
you need to run it with the /hooktest command line switch to have this
functionality enabled.
//Daniel
“Mickey Lane” wrote in message news:xxxxx@ntfsd…
>> It’s my understanding that there is a memory (or handle) leak in the
>> registry callback stuff on XP. I think it was fixed in Server 2003 SP1.
>>
>> Also, if you look at the Argument1 values (RegNtPreSetValueKey etc.)
>> for the callback on XP, Server 2003 and Vista, you’ll note a lot of
>> little differences.
>>
>> Given the two, I hook on W2K & XP and ‘go by the book’ on Vista. (I
>> don’t need to support Server.)
>>
>> Mickey.
>>
>> Don Burn wrote:
>>> No, CmRegisterCallback was XP or later. Unfortunately the only
>>> approach for Windows 2000 is hooking. Use MmGetSystemRoutineAddress
>>> to get a pointer to CmRegisterCallback if present, or otherwise have
>>> your own hooking function to get the callbacks.
>>>
>>>
>>
>
>
> —
> 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@earthlink.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Note that only with the /hooktest switch on AND you have patched the SSDT,
there becomes a third tab visible which allows you to click the necessary
buttons to perform the hook test otherwise it will not be performed. I know
it’s a bit hidden, that’s because I wanted to hide this feature from the
regular users. The hooked addresses are just obtained by analyzing the SSDT,
if you want the source of this software I can give it no problem.
//Daniel
“Mickey Lane” wrote in message news:xxxxx@ntfsd…
> Daniel,
>
> Nice. It didn’t uncover any problems in Windows 2000 running under
> VMware with or without the /hooktest switch.
>
> Are there any public code samples that show how to equate the observed
> hook address to the driver and its provider?
>
> Thanks for the pointer,
> Mickey.
>
>
> xxxxx@resplendence.com wrote:
>> If you go this way, I have a nice hook quality testing tool which checks
>> if you probe and protect the user mode parameters properly in your hooks.
>> It’s something in the style of Sysinternals NtCrash which was
>> unfortunately retracted by MS after they took over Sysinternals.
>>
>> Here it is: http://www.resplendence.com/hookanalyzer
>> you need to run it with the /hooktest command line switch to have this
>> functionality enabled.
>>
>> //Daniel
>>
>>
>> “Mickey Lane” wrote in message
>> news:xxxxx@ntfsd…
>>> It’s my understanding that there is a memory (or handle) leak in the
>>> registry callback stuff on XP. I think it was fixed in Server 2003 SP1.
>>>
>>> Also, if you look at the Argument1 values (RegNtPreSetValueKey etc.)
>>> for the callback on XP, Server 2003 and Vista, you’ll note a lot of
>>> little differences.
>>>
>>> Given the two, I hook on W2K & XP and ‘go by the book’ on Vista. (I
>>> don’t need to support Server.)
>>>
>>> Mickey.
>>>
>>> Don Burn wrote:
>>>> No, CmRegisterCallback was XP or later. Unfortunately the only
>>>> approach for Windows 2000 is hooking. Use MmGetSystemRoutineAddress to
>>>> get a pointer to CmRegisterCallback if present, or otherwise have your
>>>> own hooking function to get the callbacks.
>>>>
>>>>
>>>
>>
>>
>> —
>> 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@earthlink.net
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
Re-ran tests and discovered some things I should have done differently.
I like this tool *a lot*. Thank you.
I sent off-line e-mail about the source (or part of it) but I’m guessing
it got bounced - that happens to this a7… address a lot. Anyway, yes,
I would be interested.
Mickey.
xxxxx@resplendence.com wrote:
Note that only with the /hooktest switch on AND you have patched the
SSDT, there becomes a third tab visible which allows you to click the
necessary buttons to perform the hook test otherwise it will not be
performed. I know it’s a bit hidden, that’s because I wanted to hide
this feature from the regular users. The hooked addresses are just
obtained by analyzing the SSDT, if you want the source of this software
I can give it no problem.
//Daniel
> xxxxx@resplendence.com wrote:
>>> If you go this way, I have a nice hook quality testing tool which
>>> checks if you probe and protect the user mode parameters properly in
>>> your hooks. It’s something in the style of Sysinternals NtCrash which
>>> was unfortunately retracted by MS after they took over Sysinternals.
>>>
>>> Here it is: http://www.resplendence.com/hookanalyzer
>>> you need to run it with the /hooktest command line switch to have
>>> this functionality enabled.
>>>
>>> //Daniel
I received your mail but mine doesn’t get through to you. I suggest you
contact me with another address.
//Daniel
“Mickey Lane” wrote in message news:xxxxx@ntfsd…
> Re-ran tests and discovered some things I should have done differently.
>
> I like this tool a lot. Thank you.
>
> I sent off-line e-mail about the source (or part of it) but I’m guessing
> it got bounced - that happens to this a7… address a lot. Anyway, yes,
> I would be interested.
>
> Mickey.
>
> xxxxx@resplendence.com wrote:
>> Note that only with the /hooktest switch on AND you have patched the
>> SSDT, there becomes a third tab visible which allows you to click the
>> necessary buttons to perform the hook test otherwise it will not be
>> performed. I know it’s a bit hidden, that’s because I wanted to hide this
>> feature from the regular users. The hooked addresses are just obtained by
>> analyzing the SSDT, if you want the source of this software I can give it
>> no problem.
>>
>> //Daniel
>
>
>
> >> xxxxx@resplendence.com wrote:
> >>> If you go this way, I have a nice hook quality testing tool which
> >>> checks if you probe and protect the user mode parameters properly in
> >>> your hooks. It’s something in the style of Sysinternals NtCrash which
> >>> was unfortunately retracted by MS after they took over Sysinternals.
> >>>
> >>> Here it is: http://www.resplendence.com/hookanalyzer
> >>> you need to run it with the /hooktest command line switch to have
> >>> this functionality enabled.
> >>>
> >>> //Daniel
>
>