ZwFlushBuffersFile from kernel

NTDEV
1

Hi All,

Does anybody know the reason that ZwFlushBuffersFile() is available only
from ntdll.dll, and not from ntoskrnl.exe ?

Is there a way to do the same from kernel mode ?

Thanks,
Dror.

2

Allocate the IRP and send it down.

----- Original Message -----
From:
To: “NT Developers Interest List”
Sent: Tuesday, May 28, 2002 12:56 PM
Subject: [ntdev] ZwFlushBuffersFile from kernel

> Hi All,
>
> Does anybody know the reason that ZwFlushBuffersFile() is available
only
> from ntdll.dll, and not from ntoskrnl.exe ?
>
> Is there a way to do the same from kernel mode ?
>
> Thanks,
> Dror.
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to %%email.unsub%%
>

3

This is an interesting question. A few years back, at one of the first
Microsoft IFS plug fests, this issue was raised several times. IIRC,
someone at Microsoft said that it would be exported and exposed in a
future release.

If you are under XP, and 2000 I think, you can use the following code:

UNICODE_STRING Str;
RtlInitUnicodeString(&Str, L"ZwFlushBuffersFile");
ZwFlushBuffersFile = MmGetSystemRoutineAddress(&Str);

Remember to define the prototype and function pointer for
ZwFlushBuffersFile.

Jamey Kirby
StorageCraft, inc.
xxxxx@storagecraft.com
www.storagecraft.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@e-market.co.il
Sent: Tuesday, May 28, 2002 1:56 AM
To: NT Developers Interest List
Subject: [ntdev] ZwFlushBuffersFile from kernel

Hi All,

Does anybody know the reason that ZwFlushBuffersFile() is available only
from ntdll.dll, and not from ntoskrnl.exe ?

Is there a way to do the same from kernel mode ?

Thanks,
Dror.

You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%

4

At 18.12 28/05/2002, you wrote:

This is an interesting question. A few years back, at one of the first
Microsoft IFS plug fests, this issue was raised several times. IIRC,
someone at Microsoft said that it would be exported and exposed in a
future release.
If you are under XP, and 2000 I think, you can use the following code:
UNICODE_STRING Str;
RtlInitUnicodeString(&Str, L"ZwFlushBuffersFile");
ZwFlushBuffersFile = MmGetSystemRoutineAddress(&Str);
Remember to define the prototype and function pointer for ZwFlushBuffersFile.

Can’t drivers import ntdll.dll functions directly? after all, ntdll.dll
shows up in the drivers list, so I guess it’s accessible from kernel mode.
The only possible drawback to importing those functions is that ntdll.dll
is also accessible from user-mode, and some processes may be running with a
modified ntdll.dll (example: a tracer inserted breakpoints at the beginning
of all exported calls), but since most functions require passive IRQL, that
means you usually call them in a kernel thread, so you access System’s copy
of ntdll.dll, presumably unmodified

5

It is not exported for linking. You must dig in there and get the
pointer yourself.

Jamey Kirby
StorageCraft, inc.
xxxxx@storagecraft.com
www.storagecraft.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of KJK::Hyperion
Sent: Tuesday, May 28, 2002 11:14 AM
To: NT Developers Interest List
Subject: [ntdev] RE: ZwFlushBuffersFile from kernel

At 18.12 28/05/2002, you wrote:

This is an interesting question. A few years back, at one of the first
Microsoft IFS plug fests, this issue was raised several times. IIRC,
someone at Microsoft said that it would be exported and exposed in a
future release.
If you are under XP, and 2000 I think, you can use the following code:
UNICODE_STRING Str;
RtlInitUnicodeString(&Str, L"ZwFlushBuffersFile");
ZwFlushBuffersFile = MmGetSystemRoutineAddress(&Str);
Remember to define the prototype and function pointer for
ZwFlushBuffersFile.

Can’t drivers import ntdll.dll functions directly? after all, ntdll.dll
shows up in the drivers list, so I guess it’s accessible from kernel
mode.
The only possible drawback to importing those functions is that
ntdll.dll
is also accessible from user-mode, and some processes may be running
with a
modified ntdll.dll (example: a tracer inserted breakpoints at the
beginning
of all exported calls), but since most functions require passive IRQL,
that
means you usually call them in a kernel thread, so you access System’s
copy
of ntdll.dll, presumably unmodified

You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%

6

Mentioned ntdll.dll exports it and also ntdll.lib in XP DDK.

I would use yet another method: call int 2eh directly. The service number
may differ between OS releases but it is possible to get it from ntdll; some
SystemInternals utility shows the technique. Or maybe easier, examine all OS
releases and use correct number for current OS version.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

From: xxxxx@storagecraft.com[SMTP:xxxxx@storagecraft.com]
Reply To: xxxxx@lists.osr.com
Sent: Tuesday, May 28, 2002 10:55 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] RE: ZwFlushBuffersFile from kernel

It is not exported for linking. You must dig in there and get the
pointer yourself.

Jamey Kirby
StorageCraft, inc.
xxxxx@storagecraft.com
www.storagecraft.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of KJK::Hyperion
Sent: Tuesday, May 28, 2002 11:14 AM
To: NT Developers Interest List
Subject: [ntdev] RE: ZwFlushBuffersFile from kernel

At 18.12 28/05/2002, you wrote:
>This is an interesting question. A few years back, at one of the first
>Microsoft IFS plug fests, this issue was raised several times. IIRC,
>someone at Microsoft said that it would be exported and exposed in a
>future release.
>If you are under XP, and 2000 I think, you can use the following code:
> UNICODE_STRING Str;
> RtlInitUnicodeString(&Str, L"ZwFlushBuffersFile");
> ZwFlushBuffersFile = MmGetSystemRoutineAddress(&Str);
>Remember to define the prototype and function pointer for
ZwFlushBuffersFile.

Can’t drivers import ntdll.dll functions directly? after all, ntdll.dll
shows up in the drivers list, so I guess it’s accessible from kernel
mode.
The only possible drawback to importing those functions is that
ntdll.dll
is also accessible from user-mode, and some processes may be running
with a
modified ntdll.dll (example: a tracer inserted breakpoints at the
beginning
of all exported calls), but since most functions require passive IRQL,
that
means you usually call them in a kernel thread, so you access System’s
copy
of ntdll.dll, presumably unmodified

You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntdev as: michal.vodicka@st.com
To unsubscribe send a blank email to %%email.unsub%%

7

Id say that it can be “handcoded” directly if required, doesnt seem such a
big deal to write custom a version of this API, and
this is the preffered way over others, me thinks.

ntdll.dll resides in user space. I think that what you propose wont work,
the kernel PE loader wont solve ntdll.dll dependencies at import resolving
time.

MmGetSystemRoutineAddress works only and only with exported functions. No
name <-> entry point table is kept by kernel to work with unexported
functions.

----- Original Message -----
From: “Michal Vodicka”
To: “NT Developers Interest List”
Sent: Wednesday, May 29, 2002 12:14 AM
Subject: [ntdev] RE: ZwFlushBuffersFile from kernel

> Mentioned ntdll.dll exports it and also ntdll.lib in XP DDK.
>
> I would use yet another method: call int 2eh directly. The service number
> may differ between OS releases but it is possible to get it from ntdll;
some
> SystemInternals utility shows the technique. Or maybe easier, examine all
OS
> releases and use correct number for current OS version.
>
> Best regards,
>
> Michal Vodicka
> STMicroelectronics Design and Application s.r.o.
> [michal.vodicka@st.com, http:://www.st.com]
>
> > ----------
> > From: xxxxx@storagecraft.com[SMTP:xxxxx@storagecraft.com]
> > Reply To: xxxxx@lists.osr.com
> > Sent: Tuesday, May 28, 2002 10:55 PM
> > To: xxxxx@lists.osr.com
> > Subject: [ntdev] RE: ZwFlushBuffersFile from kernel
> >
> > It is not exported for linking. You must dig in there and get the
> > pointer yourself.
> >
> > Jamey Kirby
> > StorageCraft, inc.
> > xxxxx@storagecraft.com
> > www.storagecraft.com
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of KJK::Hyperion
> > Sent: Tuesday, May 28, 2002 11:14 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: ZwFlushBuffersFile from kernel
> >
> > At 18.12 28/05/2002, you wrote:
> > >This is an interesting question. A few years back, at one of the first
> > >Microsoft IFS plug fests, this issue was raised several times. IIRC,
> > >someone at Microsoft said that it would be exported and exposed in a
> > >future release.
> > >If you are under XP, and 2000 I think, you can use the following code:
> > > UNICODE_STRING Str;
> > > RtlInitUnicodeString(&Str, L"ZwFlushBuffersFile");
> > > ZwFlushBuffersFile = MmGetSystemRoutineAddress(&Str);
> > >Remember to define the prototype and function pointer for
> > ZwFlushBuffersFile.
> >
> > Can’t drivers import ntdll.dll functions directly? after all, ntdll.dll
> > shows up in the drivers list, so I guess it’s accessible from kernel
> > mode.
> > The only possible drawback to importing those functions is that
> > ntdll.dll
> > is also accessible from user-mode, and some processes may be running
> > with a
> > modified ntdll.dll (example: a tracer inserted breakpoints at the
> > beginning
> > of all exported calls), but since most functions require passive IRQL,
> > that
> > means you usually call them in a kernel thread, so you access System’s
> > copy
> > of ntdll.dll, presumably unmodified
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
> >
> > —
> > You are currently subscribed to ntdev as: michal.vodicka@st.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>

8

Guys, I would write my custom routine for this
not so complicated task instead of trying to
use a cannon to kill a single mosquito :-))).
However I agree that sometimes it’s necessary
to use such things, but obviously there isn’t
another solution.

Correct solution for this particular problem may be:

ObReferenceByHandle() to obtain a pointer to file object
IoGetRelatedDeviceObject() to obtain a device object from FO
IoAllocateIrp() to allocate an IRP
IoGetNextIrpStackLocation() to obtain a pointer to the next SL
---- following may be done in some generic kind of routine
KeInitializeEvent()
IoSetCompletionRoutine()
IoCallDriver()
if (Status == STATUS_PENDING)
{
KeWaitForSingleObject();
}
ObDereferenceObject() to kill our reference on FO

and in completion routine only:
KeSetEvent() and return STATUS_MORE_PROCESSING_REQUIRED.

Paul

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Michal Vodicka
Sent: Tuesday, May 28, 2002 11:15 PM
To: NT Developers Interest List
Subject: [ntdev] RE: ZwFlushBuffersFile from kernel

Mentioned ntdll.dll exports it and also ntdll.lib in XP DDK.

I would use yet another method: call int 2eh directly. The service number
may differ between OS releases but it is possible to get it from ntdll; some
SystemInternals utility shows the technique. Or maybe easier, examine all OS
releases and use correct number for current OS version.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

From: xxxxx@storagecraft.com[SMTP:xxxxx@storagecraft.com]
Reply To: xxxxx@lists.osr.com
Sent: Tuesday, May 28, 2002 10:55 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] RE: ZwFlushBuffersFile from kernel

It is not exported for linking. You must dig in there and get the
pointer yourself.

Jamey Kirby
StorageCraft, inc.
xxxxx@storagecraft.com
www.storagecraft.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of KJK::Hyperion
Sent: Tuesday, May 28, 2002 11:14 AM
To: NT Developers Interest List
Subject: [ntdev] RE: ZwFlushBuffersFile from kernel

At 18.12 28/05/2002, you wrote:
>This is an interesting question. A few years back, at one of the first
>Microsoft IFS plug fests, this issue was raised several times. IIRC,
>someone at Microsoft said that it would be exported and exposed in a
>future release.
>If you are under XP, and 2000 I think, you can use the following code:
> UNICODE_STRING Str;
> RtlInitUnicodeString(&Str, L"ZwFlushBuffersFile");
> ZwFlushBuffersFile = MmGetSystemRoutineAddress(&Str);
>Remember to define the prototype and function pointer for
ZwFlushBuffersFile.

Can’t drivers import ntdll.dll functions directly? after all, ntdll.dll
shows up in the drivers list, so I guess it’s accessible from kernel
mode.
The only possible drawback to importing those functions is that
ntdll.dll
is also accessible from user-mode, and some processes may be running
with a
modified ntdll.dll (example: a tracer inserted breakpoints at the
beginning
of all exported calls), but since most functions require passive IRQL,
that
means you usually call them in a kernel thread, so you access System’s
copy
of ntdll.dll, presumably unmodified

You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntdev as: michal.vodicka@st.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntdev as: xxxxx@compelson.com
To unsubscribe send a blank email to %%email.unsub%%

9

At 00.39 29/05/2002, you wrote:

Id say that it can be “handcoded” directly if required, doesnt seem such a
big deal to write custom a version of this API, and this is the preffered
way over others, me thinks.

ntdll.dll resides in user space.

The NT DDK drivers.exe utility reports ntdll.dll as a driver module:

ModuleName Code Data Bss Paged Init LinkDate

ntoskrnl.exe 442368 97216 0 775488 139264 Sat Apr 14 03:52:32 2001
hal.dll 33600 5536 0 31680 15680 Sun Oct 31 00:48:14 1999
BOOTVID.DLL 5664 2464 0 0 320 Thu Nov 04 02:24:33 1999
pci.sys 12864 1536 0 31456 4640 Fri Mar 02 01:38:34 2001

[…]

NTDLL.DLL 303104 12288 0 16384 0 Tue May 22 18:20:29 2001

Total 4557888 463680 0 3342464 442592

10

> Can’t drivers import ntdll.dll functions directly?

No, the kernel loader will not resolve these imports.

Max

11

----- Original Message -----
From: “KJK::Hyperion”
To: “NT Developers Interest List”
Sent: Wednesday, May 29, 2002 10:14 AM
Subject: [ntdev] RE: ZwFlushBuffersFile from kernel

> At 00.39 29/05/2002, you wrote:
> >Id say that it can be “handcoded” directly if required, doesnt seem such
a
> >big deal to write custom a version of this API, and this is the preffered
> >way over others, me thinks.
> >
> >ntdll.dll resides in user space.
>
> The NT DDK drivers.exe utility reports ntdll.dll as a driver module:
>
> ModuleName Code Data Bss Paged Init LinkDate
> --------------------------------------------------------------------------
----
> ntoskrnl.exe 442368 97216 0 775488 139264 Sat Apr 14 03:52:32
2001
> hal.dll 33600 5536 0 31680 15680 Sun Oct 31 00:48:14
1999
> BOOTVID.DLL 5664 2464 0 0 320 Thu Nov 04 02:24:33
1999
> pci.sys 12864 1536 0 31456 4640 Fri Mar 02 01:38:34
2001
>
> […]
>
> NTDLL.DLL 303104 12288 0 16384 0 Tue May 22 18:20:29
2001
> --------------------------------------------------------------------------
----
> Total 4557888 463680 0 3342464 442592
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>

12

Its not by any means a driver.

----- Original Message -----
From: “KJK::Hyperion”
To: “NT Developers Interest List”
Sent: Wednesday, May 29, 2002 10:14 AM
Subject: [ntdev] RE: ZwFlushBuffersFile from kernel

> At 00.39 29/05/2002, you wrote:
> >Id say that it can be “handcoded” directly if required, doesnt seem such
a
> >big deal to write custom a version of this API, and this is the preffered
> >way over others, me thinks.
> >
> >ntdll.dll resides in user space.
>
> The NT DDK drivers.exe utility reports ntdll.dll as a driver module:
>
> ModuleName Code Data Bss Paged Init LinkDate
> --------------------------------------------------------------------------
----
> ntoskrnl.exe 442368 97216 0 775488 139264 Sat Apr 14 03:52:32
2001
> hal.dll 33600 5536 0 31680 15680 Sun Oct 31 00:48:14
1999
> BOOTVID.DLL 5664 2464 0 0 320 Thu Nov 04 02:24:33
1999
> pci.sys 12864 1536 0 31456 4640 Fri Mar 02 01:38:34
2001
>
> […]
>
> NTDLL.DLL 303104 12288 0 16384 0 Tue May 22 18:20:29
2001
> --------------------------------------------------------------------------
----
> Total 4557888 463680 0 3342464 442592
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>

13

> >ntdll.dll resides in user space.

The NT DDK drivers.exe utility reports ntdll.dll as a driver module:

So what? Nevertheless, it is in user mode, though linked to
PsLoadedModuleList. No code in NTDLL runs in kernel mode.
The reason of this linking seems to be to provide the ability for the
kernel to query several NTDLL exports for user-mode callouts -
KiUserApcDispatcher and such.

BTW, user APC is used to initialize the process - resolve EXE’s
imports and call DllMains.

Max

14

At 22.28 29/05/2002, you wrote:

> >ntdll.dll resides in user space.
> The NT DDK drivers.exe utility reports ntdll.dll as a driver module:
So what? Nevertheless, it is in user mode, though linked to
PsLoadedModuleList. No code in NTDLL runs in kernel mode.

never said this

The reason of this linking seems to be to provide the ability for the
kernel to query several NTDLL exports for user-mode callouts -
KiUserApcDispatcher and such.

So it must be possible to do the same with ZwFlushBuffersFile, no?

BTW, user APC is used to initialize the process - resolve EXE’s imports
and call DllMains.

I know, an APC to LdrInitializeThunk is queued to the first thread of any
process. I’ve written my own subsystem, and I had to deal with this

15

> So it must be possible to do the same with ZwFlushBuffersFile, no?

Why?
The best solution is to send the flush IRP by hand, without any
tricks.

Max

16

Many things are possible , but is just another way to schratch your head,
and not necessarely a correct design. The right desing is to send a flush
IRP , grabing the file object lock if FO_SYNCHRONOUS_IO is present.

----- Original Message -----
From: “KJK::Hyperion”
To: “NT Developers Interest List”
Sent: Thursday, May 30, 2002 9:31 AM
Subject: [ntdev] RE: ZwFlushBuffersFile from kernel

> At 22.28 29/05/2002, you wrote:
> > > >ntdll.dll resides in user space.
> > > The NT DDK drivers.exe utility reports ntdll.dll as a driver module:
> >So what? Nevertheless, it is in user mode, though linked to
> >PsLoadedModuleList. No code in NTDLL runs in kernel mode.
>
> never said this
>
> >The reason of this linking seems to be to provide the ability for the
> >kernel to query several NTDLL exports for user-mode callouts -
> >KiUserApcDispatcher and such.
>
> So it must be possible to do the same with ZwFlushBuffersFile, no?
>
> >BTW, user APC is used to initialize the process - resolve EXE’s imports
> >and call DllMains.
>
> I know, an APC to LdrInitializeThunk is queued to the first thread of any
> process. I’ve written my own subsystem, and I had to deal with this
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>

17

At 21.11 30/05/2002, you wrote:

> So it must be possible to do the same with ZwFlushBuffersFile, no?
Why?

if the kernel can get the addresses of ntdll!Ki* callbacks, it must be
possible to get the address of any other routine, no? You use the same
function that drivers.exe uses to get the list of driver modules, you look
for ntdll.dll, then you do some PE magic to get the address of
ntdll!LdrGetProcedureAddress, with it you can easily get the addresses of
all other routines. Of course, only if it makes sense to do so, i.e. if you
need *several* ntdll functions

The best solution is to send the flush IRP by hand, without any tricks.

Just investigating a general solution

18

> all other routines. Of course, only if it makes sense to do so, i.e.
if you

need *several* ntdll functions

You must not have a need in NTDLL functions, since they are user-mode.
KiUserApcDispatcher is special case, it is never called by the kernel,
instead, the saved EIP in the trap frame is patched to point to it, so
KiUserApcDispatcher will be executed on return.

Max

19

> ----------

From: xxxxx@storagecraft.com[SMTP:xxxxx@storagecraft.com]
Reply To: xxxxx@lists.osr.com
Sent: Friday, May 31, 2002 8:15 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] RE: ZwFlushBuffersFile from kernel

> all other routines. Of course, only if it makes sense to do so, i.e.
if you
> need *several* ntdll functions

You must not have a need in NTDLL functions, since they are user-mode.
KiUserApcDispatcher is special case, it is never called by the kernel,
instead, the saved EIP in the trap frame is patched to point to it, so
KiUserApcDispatcher will be executed on return.

Most NTDLL functions are simple wrappers over int 2eh. It could be safe to
call them from kernel at PASSIVE_LEVEL (never tried it) It is easy to say
“you must not have need” but the need is caused by ms mistake when several
Zw functions aren’t exported by kernel. Some workaround is necessary and
this is one possibility, maybe not the best one. In this case the IRP can be
made but there are others where it isn’t possible. IIRC for example
ZwCreateSemaphore isn’t exported. The original question asked for the reason
why ZwFlushBuffersFile isn’t exported; I’d like to know too and also for
other function. Hopefully it is an omission and not mischief.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

20

In Windows 2000, the folowing special case entry points are located by
kernel from ntdll.dll .

KiUserExceptionDispatcher
KiUserApcDispatcher
KiUserCallbackDispatcher
KiRaiseUserExceptionDispatcher
LdrInitializeThunk

NPXEMULATORTABLE

As Max outlined all those entry points are
never called directly, but in x86 through a iretd instruction. It is unwise
to call user mode functions from kernel mode. Such a design breaks
the protection and security of the operating system, allowing any malevolent
code to hijack your user mode driver calling points, running
arbitrary code at CPL0. This is a no no, security is to be maintained at any
cost. you dont want your drivers to behave this way. You should
never induce security risks into a product designed for NT+. If it’s for
playing, then yes, you can doit and play as much as you want.

This happens during PspInitPahse1, and the ntdll.dll base is not fetched
from PsLoadedModuleList. Rather, during this stage ntdll.dll is mapped in
the context of the system process, and its base address is saved after a
succesfull mapping for later use. Frankly I found no evidence at all that
ntdll.dll
LdrEntry is linked into PsLoadedModuleList. Max, are you sure it is ? I
suspect that drivers.exe uses NtQuerySystemInformation to fetch this data
from kernel , API which use information from both PsLoadedModuleList AND
MmLoadedUserImageList.