RE: Need help to understand why MmProbeAndLock fails in n on-debug mod e but not in kernel debug mod

OSR_Community_User · January 18, 2005, 5:35pm

People who makes the decision may not necessarily know how it works. I am
not the one who makes the decision, but I have to make it work.

Lock 1GB memory at startup is the plan, but I can’t even lock 512MB memory
down with 2GB system memory. Interestingly enough, I was able to lock 512MB
memory when there is 1GB system memory, but failed with
ERROR_WORKING_SET_QUOTA when there is 2GB system memory.

Thanks,
zhongsheng

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Tuesday, January 18, 2005 12:21 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Need help to understand why MmProbeAndLock fails in
non-debug mod e but not in kernel debug mode

Why do you need to lock 1GB? Any reasons?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Tuesday, January 18, 2005 8:23 PM
Subject: [ntdev] Need help to understand why MmProbeAndLock fails in
non-debug
mod e but not in kernel debug mode

> Hi,
>
> What I am trying to do is to lock about 1GB memory using MmProbeAndLock()
> during process initialization. The system has 2GB memory installed. It
seems
> to work fine when I enable the kernel debugger, but when I run the code
> without the kernel debugger, the memory lock process failed. In order to
> understand why MmProbeAndLock() failed in non-kernel debug mode, I removed
> try { … …} except(…) from MmProbeAndLock() code block and force
to
> cause blue screen and generate the complete dumpfile. From the dump file,
I
> see MmProbeAndLock() throws ERROR_WORKING_SET_QUOTA exception. Here is
some
> information from the dump file. Please help me to understand why this does
> not happen when the kernel debugger is on. What can I do to prevent this
> from happening. Thanks,
>
> Exception: ERROR_WORKING_SET_QUOTA
> Arg1: c00000a1, The exception code that was not handled
> Arg2: 8051f452, The address that the exception occurred at
> Arg3: ac3f4788, Trap Frame
> Arg4: 00000000
>
> kd> .trap ac3f4788
> ESP EDITED! New esp=ac3f4b38
> ErrCode = 00000000
> eax=894b8000 ebx=c00e0b3c ecx=00000000 edx=00000000 esi=898f15d8
> edi=894b8000
> eip=8051f452 esp=ac3f47fc ebp=ac3f4bc0 iopl=0 nv up ei pl nz na pe
> nc
> cs=0000 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00000202
> nt!MmProbeAndLockPages+0x414:
> 8051f452 e96166fdff jmp nt!MmProbeAndLockPages+0x414 (804f5ab8)
>
>
> kd> x MmReferenceCountCheck
> kd> dd MmReferenceCountCheck
> 80551088 000009c4 03010218 07050705 03010218
> 80551098 06040604 00000001 00000001 804d7000
> 805510a8 0000f000 00000080 00000008 00000001
> 805510b8 0000000b 00000011 0000003b 0000000f
> 805510c8 0000000b 000000ff 000000bb ff011800
> 805510d8 ffffff04 ffffff05 ffffffff ff030200
> 805510e8 ffffff06 ffffff07 ffffffff 000003e8
> 805510f8 00000005 00000006 00000320 00004e20
>
>
> kd> u nt!MmProbeAndLockPages+0x414
> nt!MmUnlockPages+0x67:
> 804f5c48 c62c0100 mov byte ptr [ecx+eax],0x0
> 804f5c4c 008945ec8975 add [ecx+0x7589ec45],cl
> 804f5c52 f08b45ec lock mov eax,[ebp-0x14]
> 804f5c56 8b4df0 mov ecx,[ebp-0x10]
> 804f5c59 0fc101 xadd [ecx],eax
> 804f5c5c e9d8feffff jmp nt!MmUnlockPages+0x7b (804f5b39)
> 804f5c61 64a124010000 mov eax,fs:[00000124]
> 804f5c67 8b4044 mov eax,[eax+0x44]
>
>
> kd> !memusage
> loading PFN database
> loading (100% complete)
> Compiling memory usage data (99% Complete).
> Zeroed: 311055 (1244220 kb)
> Free: 0 ( 0 kb)
> Standby: 22254 ( 89016 kb)
> Modified: 746 ( 2984 kb)
> ModifiedNoWrite: 0 ( 0 kb)
> Active/Valid: 185829 (743316 kb)
> Transition: 0 ( 0 kb)
> Unknown: 0 ( 0 kb)
> TOTAL: 519884 (2079536 kb)
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@exgate.tek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · January 18, 2005, 6:11pm

Just a thought. I haven’t read the DDK documentation on this but the Win32 approximation VirtualLock talks about needing to working set of the process to be at least as large as the size of the request to VirtualLock. Your problem might be related. Doco link below.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/virtuallock.asp

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@exgate.tek.com
Sent: Wednesday, 19 January 2005 9:05 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Need help to understand why MmProbeAndLock fails in n on-debug mod e but not in kernel debug mode

People who makes the decision may not necessarily know how it works. I am
not the one who makes the decision, but I have to make it work.

Lock 1GB memory at startup is the plan, but I can’t even lock 512MB memory
down with 2GB system memory. Interestingly enough, I was able to lock 512MB
memory when there is 1GB system memory, but failed with
ERROR_WORKING_SET_QUOTA when there is 2GB system memory.

Thanks,
zhongsheng

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Tuesday, January 18, 2005 12:21 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Need help to understand why MmProbeAndLock fails in
non-debug mod e but not in kernel debug mode

Why do you need to lock 1GB? Any reasons?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Tuesday, January 18, 2005 8:23 PM
Subject: [ntdev] Need help to understand why MmProbeAndLock fails in
non-debug
mod e but not in kernel debug mode

> Hi,
>
> What I am trying to do is to lock about 1GB memory using MmProbeAndLock()
> during process initialization. The system has 2GB memory installed. It
seems
> to work fine when I enable the kernel debugger, but when I run the code
> without the kernel debugger, the memory lock process failed. In order to
> understand why MmProbeAndLock() failed in non-kernel debug mode, I removed
> try { … …} except(…) from MmProbeAndLock() code block and force
to
> cause blue screen and generate the complete dumpfile. From the dump file,
I
> see MmProbeAndLock() throws ERROR_WORKING_SET_QUOTA exception. Here is
some
> information from the dump file. Please help me to understand why this does
> not happen when the kernel debugger is on. What can I do to prevent this
> from happening. Thanks,
>
> Exception: ERROR_WORKING_SET_QUOTA
> Arg1: c00000a1, The exception code that was not handled
> Arg2: 8051f452, The address that the exception occurred at
> Arg3: ac3f4788, Trap Frame
> Arg4: 00000000
>
> kd> .trap ac3f4788
> ESP EDITED! New esp=ac3f4b38
> ErrCode = 00000000
> eax=894b8000 ebx=c00e0b3c ecx=00000000 edx=00000000 esi=898f15d8
> edi=894b8000
> eip=8051f452 esp=ac3f47fc ebp=ac3f4bc0 iopl=0 nv up ei pl nz na pe
> nc
> cs=0000 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00000202
> nt!MmProbeAndLockPages+0x414:
> 8051f452 e96166fdff jmp nt!MmProbeAndLockPages+0x414 (804f5ab8)
>
>
> kd> x MmReferenceCountCheck
> kd> dd MmReferenceCountCheck
> 80551088 000009c4 03010218 07050705 03010218
> 80551098 06040604 00000001 00000001 804d7000
> 805510a8 0000f000 00000080 00000008 00000001
> 805510b8 0000000b 00000011 0000003b 0000000f
> 805510c8 0000000b 000000ff 000000bb ff011800
> 805510d8 ffffff04 ffffff05 ffffffff ff030200
> 805510e8 ffffff06 ffffff07 ffffffff 000003e8
> 805510f8 00000005 00000006 00000320 00004e20
>
>
> kd> u nt!MmProbeAndLockPages+0x414
> nt!MmUnlockPages+0x67:
> 804f5c48 c62c0100 mov byte ptr [ecx+eax],0x0
> 804f5c4c 008945ec8975 add [ecx+0x7589ec45],cl
> 804f5c52 f08b45ec lock mov eax,[ebp-0x14]
> 804f5c56 8b4df0 mov ecx,[ebp-0x10]
> 804f5c59 0fc101 xadd [ecx],eax
> 804f5c5c e9d8feffff jmp nt!MmUnlockPages+0x7b (804f5b39)
> 804f5c61 64a124010000 mov eax,fs:[00000124]
> 804f5c67 8b4044 mov eax,[eax+0x44]
>
>
> kd> !memusage
> loading PFN database
> loading (100% complete)
> Compiling memory usage data (99% Complete).
> Zeroed: 311055 (1244220 kb)
> Free: 0 ( 0 kb)
> Standby: 22254 ( 89016 kb)
> Modified: 746 ( 2984 kb)
> ModifiedNoWrite: 0 ( 0 kb)
> Active/Valid: 185829 (743316 kb)
> Transition: 0 ( 0 kb)
> Unknown: 0 ( 0 kb)
> TOTAL: 519884 (2079536 kb)
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@exgate.tek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@dsto.defence.gov.au
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · January 18, 2005, 6:57pm

Thanks for your input. First of all, what is the difference between
VirtualLock() and MmProbeAndLock()?

I monitored the process working set size via GetProcessWorkingSetSize(). The
value returned from GetProcessWorkingSetSize() indicates that calling
MmProbeAndLock() does not affect minimumWorkingSetSize and
maxWorkingSetSize. However, if I SetProcessWorkingSetSize(0xFF00000,
0x40000000)(256MB, 1GB), the future MmProbeAndLock() will fail in my code.
So I am wondering if MmProbeAndLock() does use the process working set. If
it is, MmProbeAndLock() should pass after I increase the minWorkingSetSize
for the process. If it is not, what does ERROR_WORKING_SET_QUOTA mean in my
case? Does it mean the system working set size?

zhongsheng

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of McNally, Richard
Sent: Tuesday, January 18, 2005 3:04 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Need help to understand why MmProbeAndLock fails in n
on-debug mod e but not in kernel debug mode

Just a thought. I haven’t read the DDK documentation on this but the Win32
approximation VirtualLock talks about needing to working set of the process
to be at least as large as the size of the request to VirtualLock. Your
problem might be related. Doco link below.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base
/virtuallock.asp

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@exgate.tek.com
Sent: Wednesday, 19 January 2005 9:05 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Need help to understand why MmProbeAndLock fails in n
on-debug mod e but not in kernel debug mode

People who makes the decision may not necessarily know how it works. I am
not the one who makes the decision, but I have to make it work.

Lock 1GB memory at startup is the plan, but I can’t even lock 512MB memory
down with 2GB system memory. Interestingly enough, I was able to lock 512MB
memory when there is 1GB system memory, but failed with
ERROR_WORKING_SET_QUOTA when there is 2GB system memory.

Thanks,
zhongsheng

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Tuesday, January 18, 2005 12:21 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Need help to understand why MmProbeAndLock fails in
non-debug mod e but not in kernel debug mode

Why do you need to lock 1GB? Any reasons?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Tuesday, January 18, 2005 8:23 PM
Subject: [ntdev] Need help to understand why MmProbeAndLock fails in
non-debug
mod e but not in kernel debug mode

> Hi,
>
> What I am trying to do is to lock about 1GB memory using MmProbeAndLock()
> during process initialization. The system has 2GB memory installed. It
seems
> to work fine when I enable the kernel debugger, but when I run the code
> without the kernel debugger, the memory lock process failed. In order to
> understand why MmProbeAndLock() failed in non-kernel debug mode, I removed
> try { … …} except(…) from MmProbeAndLock() code block and force
to
> cause blue screen and generate the complete dumpfile. From the dump file,
I
> see MmProbeAndLock() throws ERROR_WORKING_SET_QUOTA exception. Here is
some
> information from the dump file. Please help me to understand why this does
> not happen when the kernel debugger is on. What can I do to prevent this
> from happening. Thanks,
>
> Exception: ERROR_WORKING_SET_QUOTA
> Arg1: c00000a1, The exception code that was not handled
> Arg2: 8051f452, The address that the exception occurred at
> Arg3: ac3f4788, Trap Frame
> Arg4: 00000000
>
> kd> .trap ac3f4788
> ESP EDITED! New esp=ac3f4b38
> ErrCode = 00000000
> eax=894b8000 ebx=c00e0b3c ecx=00000000 edx=00000000 esi=898f15d8
> edi=894b8000
> eip=8051f452 esp=ac3f47fc ebp=ac3f4bc0 iopl=0 nv up ei pl nz na pe
> nc
> cs=0000 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00000202
> nt!MmProbeAndLockPages+0x414:
> 8051f452 e96166fdff jmp nt!MmProbeAndLockPages+0x414 (804f5ab8)
>
>
> kd> x MmReferenceCountCheck
> kd> dd MmReferenceCountCheck
> 80551088 000009c4 03010218 07050705 03010218
> 80551098 06040604 00000001 00000001 804d7000
> 805510a8 0000f000 00000080 00000008 00000001
> 805510b8 0000000b 00000011 0000003b 0000000f
> 805510c8 0000000b 000000ff 000000bb ff011800
> 805510d8 ffffff04 ffffff05 ffffffff ff030200
> 805510e8 ffffff06 ffffff07 ffffffff 000003e8
> 805510f8 00000005 00000006 00000320 00004e20
>
>
> kd> u nt!MmProbeAndLockPages+0x414
> nt!MmUnlockPages+0x67:
> 804f5c48 c62c0100 mov byte ptr [ecx+eax],0x0
> 804f5c4c 008945ec8975 add [ecx+0x7589ec45],cl
> 804f5c52 f08b45ec lock mov eax,[ebp-0x14]
> 804f5c56 8b4df0 mov ecx,[ebp-0x10]
> 804f5c59 0fc101 xadd [ecx],eax
> 804f5c5c e9d8feffff jmp nt!MmUnlockPages+0x7b (804f5b39)
> 804f5c61 64a124010000 mov eax,fs:[00000124]
> 804f5c67 8b4044 mov eax,[eax+0x44]
>
>
> kd> !memusage
> loading PFN database
> loading (100% complete)
> Compiling memory usage data (99% Complete).
> Zeroed: 311055 (1244220 kb)
> Free: 0 ( 0 kb)
> Standby: 22254 ( 89016 kb)
> Modified: 746 ( 2984 kb)
> ModifiedNoWrite: 0 ( 0 kb)
> Active/Valid: 185829 (743316 kb)
> Transition: 0 ( 0 kb)
> Unknown: 0 ( 0 kb)
> TOTAL: 519884 (2079536 kb)
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@exgate.tek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@dsto.defence.gov.au
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@exgate.tek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Maxim_S_Shatskih · January 19, 2005, 6:51am

> People who makes the decision may not necessarily know how it works. I am

not the one who makes the decision, but I have to make it work.

Then your decision-maker is nearly surely wrong, and you should explain it to
him.

Otherwise, there are major chances you will have a technically inferiour
product.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

OSR_Community_User · January 19, 2005, 12:51pm

Thanks, Jack:

I am calling MmProbeAndLock() in user application’s process context not in
system thread context. What I don’t understand is that MmProbeAndLock()
512MB works when the system has 1GB memory, but does not work when the
system has 2GB memory. Do you know anything about it?

Thanks again,
zhongsheng

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jack Heeley
Sent: Wednesday, January 19, 2005 2:57 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Need help to understand why MmProbeAndLock fails in
non-debug mod e but not in kernel debug mode

Quota’s are charged to processes. In what context are you calling
MmProbeAndLock()?

If this is arbitrary thread context the behaviour could change for many
reasons (including changing from debug to non-debug mode). You probably
want to do this in a system thread (e.g. use PsCreateSystemThread) so the
call is made under the system process. I would imagine this maximize your
quota allowance, though I don’t know if that will resolve your problem.

Resource strategies are different on workstation and server versions of the
operating system. This is more likely to work on the server version if that
is an option.

Jack.

wrote in message news:xxxxx@ntdev…
> Hi,
>
> What I am trying to do is to lock about 1GB memory using MmProbeAndLock()
> during process initialization. The system has 2GB memory installed. It
seems
> to work fine when I enable the kernel debugger, but when I run the code
> without the kernel debugger, the memory lock process failed. In order to
> understand why MmProbeAndLock() failed in non-kernel debug mode, I removed
> try { … …} except(…) from MmProbeAndLock() code block and force
to
> cause blue screen and generate the complete dumpfile. From the dump file,
I
> see MmProbeAndLock() throws ERROR_WORKING_SET_QUOTA exception. Here is
some
> information from the dump file. Please help me to understand why this does
> not happen when the kernel debugger is on. What can I do to prevent this
> from happening. Thanks,
>
> Exception: ERROR_WORKING_SET_QUOTA
> Arg1: c00000a1, The exception code that was not handled
> Arg2: 8051f452, The address that the exception occurred at
> Arg3: ac3f4788, Trap Frame
> Arg4: 00000000
>
> kd> .trap ac3f4788
> ESP EDITED! New esp=ac3f4b38
> ErrCode = 00000000
> eax=894b8000 ebx=c00e0b3c ecx=00000000 edx=00000000 esi=898f15d8
> edi=894b8000
> eip=8051f452 esp=ac3f47fc ebp=ac3f4bc0 iopl=0 nv up ei pl nz na pe
> nc
> cs=0000 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00000202
> nt!MmProbeAndLockPages+0x414:
> 8051f452 e96166fdff jmp nt!MmProbeAndLockPages+0x414 (804f5ab8)
>
>
> kd> x MmReferenceCountCheck
> kd> dd MmReferenceCountCheck
> 80551088 000009c4 03010218 07050705 03010218
> 80551098 06040604 00000001 00000001 804d7000
> 805510a8 0000f000 00000080 00000008 00000001
> 805510b8 0000000b 00000011 0000003b 0000000f
> 805510c8 0000000b 000000ff 000000bb ff011800
> 805510d8 ffffff04 ffffff05 ffffffff ff030200
> 805510e8 ffffff06 ffffff07 ffffffff 000003e8
> 805510f8 00000005 00000006 00000320 00004e20
>
>
> kd> u nt!MmProbeAndLockPages+0x414
> nt!MmUnlockPages+0x67:
> 804f5c48 c62c0100 mov byte ptr [ecx+eax],0x0
> 804f5c4c 008945ec8975 add [ecx+0x7589ec45],cl
> 804f5c52 f08b45ec lock mov eax,[ebp-0x14]
> 804f5c56 8b4df0 mov ecx,[ebp-0x10]
> 804f5c59 0fc101 xadd [ecx],eax
> 804f5c5c e9d8feffff jmp nt!MmUnlockPages+0x7b (804f5b39)
> 804f5c61 64a124010000 mov eax,fs:[00000124]
> 804f5c67 8b4044 mov eax,[eax+0x44]
>
>
> kd> !memusage
> loading PFN database
> loading (100% complete)
> Compiling memory usage data (99% Complete).
> Zeroed: 311055 (1244220 kb)
> Free: 0 ( 0 kb)
> Standby: 22254 ( 89016 kb)
> Modified: 746 ( 2984 kb)
> ModifiedNoWrite: 0 ( 0 kb)
> Active/Valid: 185829 (743316 kb)
> Transition: 0 ( 0 kb)
> Unknown: 0 ( 0 kb)
> TOTAL: 519884 (2079536 kb)
>
>
>
>
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@exgate.tek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Jack_Heeley · January 20, 2005, 6:01am

Hi zhongsheng,

The availability of extra memory can be detected by other system components
and drivers (e.g. using MmQuerySystemSize) and they are free to decide that
with 2GB available it is reasonable to employ a different memory usage
strategy. If they do this too aggressively, the working set size could be
dynamically adjusted downwards by Windows.

This is just one hypothetical scenario where there is more physical memory
but every process gets less.

It might not be exactly what’s happening in your case, but the point is that
quotas are dynamic values and affected by circumstances. Because of that
fact you can’t expect complete consistency from run to run. If you change
the system load by changing the set of processes running, you can quite
feasibly trigger a non-intuitive response (like the one you see - more
physical memory but less quota). So yes its surprising, but no its not
incomprehensible, and clearly not impossible.

Quotas are a form of rationing to ensure a fair distribution of the
currently remaining resources amongst processes. But the scarecity of a
resource depends on the history of its use. See
http://www.osronline.com/article.cfm?id=60

You’ll see there that process maximum working set quota value is assigned
when a process is created can be changed by program (depending on
privileges) and can also change dynamically (presumably depending on the
current memory resource loading).

You might be able to use this to force the matter, (for example, the Win32
function SetProcessWorkingSetSize, or a kernel version of this, although I
haven’t been able to find/identify one myself).

If your systems are dedicated to your particular purpose alone or a
relatively predictable load then this MIGHT just be a practical solution. I
wouldn’t recommend it since the quota is dynamic, where goes the guarantee?
If your software must co-exist on a workstation or server that is being used
for other purposes, forcing the matter, even if its possible, really isn’t a
good idea.

My practical tips…

Trace the output from GetProcessWorkingSetSize will help you confirm (or
disprove) that there is a relationship between this issue and your driver
exception.

You can then experiment with the amount of available memory. You don’t need
to physically remove banks of memory! See Windows DDK help at Windows
DDK->Driver Development Tools->The boo.ini File->Parameters for the boot.ini
File /maxmem=sizeInMB.

2GB is a threashold value. See what happens to the quota when you reduce
memory by various amounts, and collect this in an an excel
spreadsheet/report. If the experimental relationship is not repeatable,
direct and predictable (e.g. linear/stepped), then this is evidence that
proves the weakness of a design assumption. That would be clear evidence
proving that this approach is not reliable.

Nobody likes a redesign, least of all a boss who only thinks he
understands the technical issues, and reports to somebody who doesn’t care
about technical issues at all! So evidence is needed. If you use an excel
spreadheet and graph, you help your boss to present the bad news, rather
than just hiding, hoping, pouring more pressure on, and peparing to cover
his own ass. Be certain, if you don’t do this you will be first in line for
blame when the project fails. So keep it on record too.

Keep asking and seek out ways where the quota allocation can be made
(more) predictable. Perhaps this can be controlled through system settings
configurable through the registry? If you can crack that nut, then your
design approach is, lets say, not subtle, maybe even brutal, but basically
ok.
Refer your boss to the Nash Equlibrium - Strategies for n-player
non-cooperative games, for a formal treatment supporting your conclusions.
That might make him stop and think again. Make sure you give the impression
that to you its “obvious” and you understand every sentence and formula, and
that it definitely supports your argument. Trust me, it always does!

Good luck,

Jack.

wrote in message news:xxxxx@ntdev…
> Thanks, Jack:
>
> I am calling MmProbeAndLock() in user application’s process context not in
> system thread context. What I don’t understand is that MmProbeAndLock()
> 512MB works when the system has 1GB memory, but does not work when the
> system has 2GB memory. Do you know anything about it?
>
> Thanks again,
> zhongsheng
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Jack Heeley
> Sent: Wednesday, January 19, 2005 2:57 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Need help to understand why MmProbeAndLock fails in
> non-debug mod e but not in kernel debug mode
>
> Quota’s are charged to processes. In what context are you calling
> MmProbeAndLock()?
>
> If this is arbitrary thread context the behaviour could change for many
> reasons (including changing from debug to non-debug mode). You probably
> want to do this in a system thread (e.g. use PsCreateSystemThread) so the
> call is made under the system process. I would imagine this maximize your
> quota allowance, though I don’t know if that will resolve your problem.
>
> Resource strategies are different on workstation and server versions of
the
> operating system. This is more likely to work on the server version if
that
> is an option.
>
> Jack.
>
> wrote in message news:xxxxx@ntdev…
> > Hi,
> >
> > What I am trying to do is to lock about 1GB memory using
MmProbeAndLock()
> > during process initialization. The system has 2GB memory installed. It
> seems
> > to work fine when I enable the kernel debugger, but when I run the code
> > without the kernel debugger, the memory lock process failed. In order to
> > understand why MmProbeAndLock() failed in non-kernel debug mode, I
removed
> > try { … …} except(…) from MmProbeAndLock() code block and
force
> to
> > cause blue screen and generate the complete dumpfile. From the dump
file,
> I
> > see MmProbeAndLock() throws ERROR_WORKING_SET_QUOTA exception. Here is
> some
> > information from the dump file. Please help me to understand why this
does
> > not happen when the kernel debugger is on. What can I do to prevent this
> > from happening. Thanks,
> >
> > Exception: ERROR_WORKING_SET_QUOTA
> > Arg1: c00000a1, The exception code that was not handled
> > Arg2: 8051f452, The address that the exception occurred at
> > Arg3: ac3f4788, Trap Frame
> > Arg4: 00000000
> >
> > kd> .trap ac3f4788
> > ESP EDITED! New esp=ac3f4b38
> > ErrCode = 00000000
> > eax=894b8000 ebx=c00e0b3c ecx=00000000 edx=00000000 esi=898f15d8
> > edi=894b8000
> > eip=8051f452 esp=ac3f47fc ebp=ac3f4bc0 iopl=0 nv up ei pl nz na
pe
> > nc
> > cs=0000 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> > efl=00000202
> > nt!MmProbeAndLockPages+0x414:
> > 8051f452 e96166fdff jmp nt!MmProbeAndLockPages+0x414
(804f5ab8)
> >
> >
> > kd> x MmReferenceCountCheck
> > kd> dd MmReferenceCountCheck
> > 80551088 000009c4 03010218 07050705 03010218
> > 80551098 06040604 00000001 00000001 804d7000
> > 805510a8 0000f000 00000080 00000008 00000001
> > 805510b8 0000000b 00000011 0000003b 0000000f
> > 805510c8 0000000b 000000ff 000000bb ff011800
> > 805510d8 ffffff04 ffffff05 ffffffff ff030200
> > 805510e8 ffffff06 ffffff07 ffffffff 000003e8
> > 805510f8 00000005 00000006 00000320 00004e20
> >
> >
> > kd> u nt!MmProbeAndLockPages+0x414
> > nt!MmUnlockPages+0x67:
> > 804f5c48 c62c0100 mov byte ptr [ecx+eax],0x0
> > 804f5c4c 008945ec8975 add [ecx+0x7589ec45],cl
> > 804f5c52 f08b45ec lock mov eax,[ebp-0x14]
> > 804f5c56 8b4df0 mov ecx,[ebp-0x10]
> > 804f5c59 0fc101 xadd [ecx],eax
> > 804f5c5c e9d8feffff jmp nt!MmUnlockPages+0x7b (804f5b39)
> > 804f5c61 64a124010000 mov eax,fs:[00000124]
> > 804f5c67 8b4044 mov eax,[eax+0x44]
> >
> >
> > kd> !memusage
> > loading PFN database
> > loading (100% complete)
> > Compiling memory usage data (99% Complete).
> > Zeroed: 311055 (1244220 kb)
> > Free: 0 ( 0 kb)
> > Standby: 22254 ( 89016 kb)
> > Modified: 746 ( 2984 kb)
> > ModifiedNoWrite: 0 ( 0 kb)
> > Active/Valid: 185829 (743316 kb)
> > Transition: 0 ( 0 kb)
> > Unknown: 0 ( 0 kb)
> > TOTAL: 519884 (2079536 kb)
> >
> >
> >
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@exgate.tek.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>