Problem with RtlQueryRegistryValues

NTDEV
1

I have been using the RtlQueryRegistryValues function to read REG_DWORD
values from the registry. Now I need to read a REG_EXPAND_SZ value. I
reviewed the DDK documentation (the online version) and I believe I have set
the RTL_QUERY_REGISTRY_TABLE up correctly.
paramTable[3].Flags = RTL_QUERY_REGISTRY_DIRECT;
paramTable[3].Name = L"FPGAFileName";
paramTable[3].EntryContext = fpgaFileName; // Pointer to UNICODE_STRING
paramTable[3].DefaultType = REG_EXPAND_SZ;
paramTable[3].DefaultData = L"";
paramTable[3].DefaultLength = 0;

This is the last entry in the paramTable. The values at paramTable[4] are
all zero’ed.

If the REG_EXPAND_SZ value does not contain any environment variables
everything works fine. RtlQueryRegistryValues returns the string in my
supplied unicode buffer (fpgaFileName). However, if the registry value
contains an environment varialbe (%SystemRoot% for example) I get the blue
screen below.

The problem appears that RtlQueryEnvironmentVariable_U is either not loaded
in memory or has the wrong address. I verified that I am running at IRQL
Passive Level.

Does anyone have any ideas what I might be doing wrong?

  • Steve -

0: kd> !analyze -v
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by
try-except,
it must be protected by a Probe. Typically the address is just plain bad or
it
is pointing at freed memory.
Arguments:
Arg1: 80681cb4, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 80681cb4, If non-zero, the instruction address which referenced the
bad memory
address.
Arg4: 00000000, (reserved)

Debugging Details:

READ_ADDRESS: 80681cb4

FAULTING_IP:
nt!RtlQueryEnvironmentVariable_U+0
80681cb4 ?? ???

MM_INTERNAL_CODE: 0

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x50

LAST_CONTROL_TRANSFER: from 804f428c to 8051d4b0

STACK_TEXT:
fc9172fc 804f428c 00000003 804d4000 80681cb4
nt!RtlpBreakWithStatusInstruction
fc917348 804f4d11 00000003 806bb8cc c0201a04 nt!KiBugCheckDebugBreak+0x19
fc917714 804f52af 00000050 80681cb4 00000000 nt!KeBugCheck2+0x46d
fc917734 8051445e 00000050 80681cb4 00000000 nt!KeBugCheckEx+0x19
fc917784 80532fa8 00000000 80681cb4 00000000 nt!MmAccessFault+0x758
fc917784 80681cb4 00000000 80681cb4 00000000 nt!KiTrap0E+0xbc
fc91780c 805c5f92 00000000 fc917834 fc91782c
nt!RtlQueryEnvironmentVariable_U
fc91784c 805c66de 00000000 00000082 fc917878
nt!RtlExpandEnvironmentStrings_U+0xb6
fc917890 805c6ade fc917970 e1dc2604 fc9178f0
nt!RtlpCallQueryRegistryRoutine+0x2db
fc9178f4 f772965d 00000000 00000084 00000001 nt!RtlQueryRegistryValues+0x2a4
fc9179c4 f77255dd 00000064 f7730018 81255e40
fg8000!cfFg8000GetDeviceParamsFromRegistry+0x17b [c:/fg8000/entrycom.c @
494]
fc9179f4 804f2a40 ff9de2d0 81255e40 00000000 fg8000!cfFg8000AddDevice+0xdf
[c:/fg8000/pnp.c @ 166]
fc917a10 80574afe f77254fe 00000004 00000001 nt!PpvUtilCallAddDevice+0x2c
fc917ad8 80575d29 00000000 02000001 00000000 nt!PipCallDriverAddDevice+0x374
fc917d24 8057620e 81255738 00000001 00000000 nt!PipProcessDevNodeTree+0x147
fc917d54 804f2120 00000003 805482c0 8054d0dc nt!PiRestartDevice+0x7e
fc917d7c 80528267 00000000 00000000 81275b30 nt!PipDeviceActionWorker+0x15a
fc917dac 805b046c 00000000 00000000 00000000 nt!ExpWorkerThread+0xed
fc917ddc 80534ad6 8052817a 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FAILED_INSTRUCTION_ADDRESS:
nt!RtlQueryEnvironmentVariable_U+0
80681cb4 ?? ???

FOLLOWUP_IP:
fg8000!cfFg8000GetDeviceParamsFromRegistry+17b
f772965d ff75f4 push dword ptr [ebp-0xc]

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: fg8000!cfFg8000GetDeviceParamsFromRegistry+17b

MODULE_NAME: fg8000

IMAGE_NAME: fg8000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3ea5d39a

STACK_COMMAND: kb

BUCKET_ID:
0x50_CODE_AV_BAD_IP_fg8000!cfFg8000GetDeviceParamsFromRegistry+17b

Followup: MachineOwner

2

Environment variables are a user-mode per-process thing (stored off the
PEB). There’s really no concept of system environment variables.

So you might be able to get them from the calling process in an IOCTL
(though I’d be surprised) but you can’t get at them during PNP
operations, from system threads, or other times when you’re not in the
client process address space.

-p

This posting is provided “AS IS” with no warranties, and confers no
rights

-----Original Message-----
From: Whitman, Steve [mailto:xxxxx@cognex.com]
Sent: Wednesday, April 23, 2003 12:01 PM
To: NT Developers Interest List

I have been using the RtlQueryRegistryValues function to read REG_DWORD
values from the registry. Now I need to read a REG_EXPAND_SZ value. I
reviewed the DDK documentation (the online version) and I believe I have
set the RTL_QUERY_REGISTRY_TABLE up correctly.
paramTable[3].Flags = RTL_QUERY_REGISTRY_DIRECT;
paramTable[3].Name = L"FPGAFileName";
paramTable[3].EntryContext = fpgaFileName; // Pointer to
UNICODE_STRING
paramTable[3].DefaultType = REG_EXPAND_SZ;
paramTable[3].DefaultData = L"";
paramTable[3].DefaultLength = 0;

This is the last entry in the paramTable. The values at paramTable[4]
are all zero’ed.

If the REG_EXPAND_SZ value does not contain any environment variables
everything works fine. RtlQueryRegistryValues returns the string in my
supplied unicode buffer (fpgaFileName). However, if the registry value
contains an environment varialbe (%SystemRoot% for example) I get the
blue screen below.

The problem appears that RtlQueryEnvironmentVariable_U is either not
loaded in memory or has the wrong address. I verified that I am running
at IRQL Passive Level.

Does anyone have any ideas what I might be doing wrong?

  • Steve -

0: kd> !analyze -v
************************************************************************
****
***
*
*
* Bugcheck Analysis
*
*
*
************************************************************************
****
***

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by
try-except, it must be protected by a Probe. Typically the address is
just plain bad or it is pointing at freed memory.
Arguments:
Arg1: 80681cb4, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 80681cb4, If non-zero, the instruction address which referenced
the bad memory
address.
Arg4: 00000000, (reserved)

Debugging Details:

READ_ADDRESS: 80681cb4

FAULTING_IP:
nt!RtlQueryEnvironmentVariable_U+0
80681cb4 ?? ???

MM_INTERNAL_CODE: 0

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x50

LAST_CONTROL_TRANSFER: from 804f428c to 8051d4b0

STACK_TEXT:
fc9172fc 804f428c 00000003 804d4000 80681cb4
nt!RtlpBreakWithStatusInstruction
fc917348 804f4d11 00000003 806bb8cc c0201a04
nt!KiBugCheckDebugBreak+0x19
fc917714 804f52af 00000050 80681cb4 00000000 nt!KeBugCheck2+0x46d
fc917734 8051445e 00000050 80681cb4 00000000 nt!KeBugCheckEx+0x19
fc917784 80532fa8 00000000 80681cb4 00000000 nt!MmAccessFault+0x758
fc917784 80681cb4 00000000 80681cb4 00000000 nt!KiTrap0E+0xbc fc91780c
805c5f92 00000000 fc917834 fc91782c nt!RtlQueryEnvironmentVariable_U
fc91784c 805c66de 00000000 00000082 fc917878
nt!RtlExpandEnvironmentStrings_U+0xb6
fc917890 805c6ade fc917970 e1dc2604 fc9178f0
nt!RtlpCallQueryRegistryRoutine+0x2db
fc9178f4 f772965d 00000000 00000084 00000001
nt!RtlQueryRegistryValues+0x2a4
fc9179c4 f77255dd 00000064 f7730018 81255e40
fg8000!cfFg8000GetDeviceParamsFromRegistry+0x17b [c:/fg8000/entrycom.c @
494]
fc9179f4 804f2a40 ff9de2d0 81255e40 00000000
fg8000!cfFg8000AddDevice+0xdf [c:/fg8000/pnp.c @ 166] fc917a10 80574afe
f77254fe 00000004 00000001 nt!PpvUtilCallAddDevice+0x2c
fc917ad8 80575d29 00000000 02000001 00000000
nt!PipCallDriverAddDevice+0x374
fc917d24 8057620e 81255738 00000001 00000000
nt!PipProcessDevNodeTree+0x147
fc917d54 804f2120 00000003 805482c0 8054d0dc nt!PiRestartDevice+0x7e
fc917d7c 80528267 00000000 00000000 81275b30
nt!PipDeviceActionWorker+0x15a fc917dac 805b046c 00000000 00000000
00000000 nt!ExpWorkerThread+0xed fc917ddc 80534ad6 8052817a 00000001
00000000 nt!PspSystemThreadStartup+0x34 00000000 00000000 00000000
00000000 00000000 nt!KiThreadStartup+0x16

FAILED_INSTRUCTION_ADDRESS:
nt!RtlQueryEnvironmentVariable_U+0
80681cb4 ?? ???

FOLLOWUP_IP:
fg8000!cfFg8000GetDeviceParamsFromRegistry+17b
f772965d ff75f4 push dword ptr [ebp-0xc]

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: fg8000!cfFg8000GetDeviceParamsFromRegistry+17b

MODULE_NAME: fg8000

IMAGE_NAME: fg8000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3ea5d39a

STACK_COMMAND: kb

BUCKET_ID:
0x50_CODE_AV_BAD_IP_fg8000!cfFg8000GetDeviceParamsFromRegistry+17b

Followup: MachineOwner

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

3

Thanks for the information. The DDK doc didn’t provide any information that
REG_EXPAND_SZ could only be used in the context of another process. The
docs even provide information about REG_EXPAND_SZ so I thought it would be
alright to us it.

BTW, I didn’t think I would be able to get user environment variables but I
thought that the “system” environment variables would be available.

  • Steve -

-----Original Message-----
From: Peter Wieland [mailto:xxxxx@windows.microsoft.com]
Sent: Wednesday, April 23, 2003 3:14 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with RtlQueryRegistryValues

Environment variables are a user-mode per-process thing
(stored off the
PEB). There’s really no concept of system environment variables.

So you might be able to get them from the calling process in an IOCTL
(though I’d be surprised) but you can’t get at them during PNP
operations, from system threads, or other times when you’re not in the
client process address space.

-p

This posting is provided “AS IS” with no warranties, and confers no
rights

-----Original Message-----
From: Whitman, Steve [mailto:xxxxx@cognex.com]
Sent: Wednesday, April 23, 2003 12:01 PM
To: NT Developers Interest List

I have been using the RtlQueryRegistryValues function to read
REG_DWORD
values from the registry. Now I need to read a REG_EXPAND_SZ
value. I
reviewed the DDK documentation (the online version) and I
believe I have
set the RTL_QUERY_REGISTRY_TABLE up correctly.
paramTable[3].Flags = RTL_QUERY_REGISTRY_DIRECT;
paramTable[3].Name = L"FPGAFileName";
paramTable[3].EntryContext = fpgaFileName; // Pointer to
UNICODE_STRING
paramTable[3].DefaultType = REG_EXPAND_SZ;
paramTable[3].DefaultData = L"";
paramTable[3].DefaultLength = 0;

This is the last entry in the paramTable. The values at paramTable[4]
are all zero’ed.

If the REG_EXPAND_SZ value does not contain any environment variables
everything works fine. RtlQueryRegistryValues returns the
string in my
supplied unicode buffer (fpgaFileName). However, if the
registry value
contains an environment varialbe (%SystemRoot% for example) I get the
blue screen below.

The problem appears that RtlQueryEnvironmentVariable_U is either not
loaded in memory or has the wrong address. I verified that I
am running
at IRQL Passive Level.

Does anyone have any ideas what I might be doing wrong?

  • Steve -

0: kd> !analyze -v
**************************************************************
**********
****
***
*
*
* Bugcheck Analysis
*
*
*
**************************************************************
**********
****
***

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by
try-except, it must be protected by a Probe. Typically the address is
just plain bad or it is pointing at freed memory.
Arguments:
Arg1: 80681cb4, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 80681cb4, If non-zero, the instruction address which referenced
the bad memory
address.
Arg4: 00000000, (reserved)

Debugging Details:

READ_ADDRESS: 80681cb4

FAULTING_IP:
nt!RtlQueryEnvironmentVariable_U+0
80681cb4 ?? ???

MM_INTERNAL_CODE: 0

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x50

LAST_CONTROL_TRANSFER: from 804f428c to 8051d4b0

STACK_TEXT:
fc9172fc 804f428c 00000003 804d4000 80681cb4
nt!RtlpBreakWithStatusInstruction
fc917348 804f4d11 00000003 806bb8cc c0201a04
nt!KiBugCheckDebugBreak+0x19
fc917714 804f52af 00000050 80681cb4 00000000 nt!KeBugCheck2+0x46d
fc917734 8051445e 00000050 80681cb4 00000000 nt!KeBugCheckEx+0x19
fc917784 80532fa8 00000000 80681cb4 00000000 nt!MmAccessFault+0x758
fc917784 80681cb4 00000000 80681cb4 00000000 nt!KiTrap0E+0xbc fc91780c
805c5f92 00000000 fc917834 fc91782c nt!RtlQueryEnvironmentVariable_U
fc91784c 805c66de 00000000 00000082 fc917878
nt!RtlExpandEnvironmentStrings_U+0xb6
fc917890 805c6ade fc917970 e1dc2604 fc9178f0
nt!RtlpCallQueryRegistryRoutine+0x2db
fc9178f4 f772965d 00000000 00000084 00000001
nt!RtlQueryRegistryValues+0x2a4
fc9179c4 f77255dd 00000064 f7730018 81255e40
fg8000!cfFg8000GetDeviceParamsFromRegistry+0x17b
[c:/fg8000/entrycom.c @
494]
fc9179f4 804f2a40 ff9de2d0 81255e40 00000000
fg8000!cfFg8000AddDevice+0xdf [c:/fg8000/pnp.c @ 166]
fc917a10 80574afe
f77254fe 00000004 00000001 nt!PpvUtilCallAddDevice+0x2c
fc917ad8 80575d29 00000000 02000001 00000000
nt!PipCallDriverAddDevice+0x374
fc917d24 8057620e 81255738 00000001 00000000
nt!PipProcessDevNodeTree+0x147
fc917d54 804f2120 00000003 805482c0 8054d0dc nt!PiRestartDevice+0x7e
fc917d7c 80528267 00000000 00000000 81275b30
nt!PipDeviceActionWorker+0x15a fc917dac 805b046c 00000000 00000000
00000000 nt!ExpWorkerThread+0xed fc917ddc 80534ad6 8052817a 00000001
00000000 nt!PspSystemThreadStartup+0x34 00000000 00000000 00000000
00000000 00000000 nt!KiThreadStartup+0x16

FAILED_INSTRUCTION_ADDRESS:
nt!RtlQueryEnvironmentVariable_U+0
80681cb4 ?? ???

FOLLOWUP_IP:
fg8000!cfFg8000GetDeviceParamsFromRegistry+17b
f772965d ff75f4 push dword ptr [ebp-0xc]

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: fg8000!cfFg8000GetDeviceParamsFromRegistry+17b

MODULE_NAME: fg8000

IMAGE_NAME: fg8000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3ea5d39a

STACK_COMMAND: kb

BUCKET_ID:
0x50_CODE_AV_BAD_IP_fg8000!cfFg8000GetDeviceParamsFromRegistry+17b

Followup: MachineOwner

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

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

4

> Thanks for the information. The DDK doc didn’t provide any information

that
REG_EXPAND_SZ could only be used in the context of another process.
The
docs even provide information about REG_EXPAND_SZ so I thought it would
be
alright to us it.

However, the call should not bugcheck, so while environment expansion
might not work, it does not explain the system crash.

===========================
Mark Roddy
Consultant, Microsoft DDK MVP
Hollis Technology Solutions
xxxxx@hollistech.com
www.hollistech.com
603-321-1032

5

the registry is the “system environment variables” :slight_smile:

the safest approach to take with the DDK is to assume that it’s not safe
to use unless it is documented. It’s very hard to document everything a
driver shouldn’t do.

-p

-----Original Message-----
From: Whitman, Steve [mailto:xxxxx@cognex.com]
Sent: Thursday, April 24, 2003 5:37 AM
To: NT Developers Interest List

Thanks for the information. The DDK doc didn’t provide any
information that REG_EXPAND_SZ could only be used in the
context of another process. The docs even provide
information about REG_EXPAND_SZ so I thought it would be
alright to us it.

BTW, I didn’t think I would be able to get user environment
variables but I thought that the “system” environment
variables would be available.

  • Steve -

> -----Original Message-----
> From: Peter Wieland [mailto:xxxxx@windows.microsoft.com]
> Sent: Wednesday, April 23, 2003 3:14 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Problem with RtlQueryRegistryValues
>
>
> Environment variables are a user-mode per-process thing (stored off
> the PEB). There’s really no concept of system environment
variables.
>
> So you might be able to get them from the calling process
in an IOCTL
> (though I’d be surprised) but you can’t get at them during PNP
> operations, from system threads, or other times when you’re
not in the
> client process address space.
>
> -p
>
>
> This posting is provided “AS IS” with no warranties, and confers no
> rights
>
>
>
> -----Original Message-----
> From: Whitman, Steve [mailto:xxxxx@cognex.com]
> Sent: Wednesday, April 23, 2003 12:01 PM
> To: NT Developers Interest List
>
> I have been using the RtlQueryRegistryValues function to read
> REG_DWORD values from the registry. Now I need to read a
> REG_EXPAND_SZ value. I reviewed the DDK documentation (the online
> version) and I believe I have set the RTL_QUERY_REGISTRY_TABLE up
> correctly.
> paramTable[3].Flags = RTL_QUERY_REGISTRY_DIRECT;
> paramTable[3].Name = L"FPGAFileName";
> paramTable[3].EntryContext = fpgaFileName; // Pointer to
> UNICODE_STRING
> paramTable[3].DefaultType = REG_EXPAND_SZ;
> paramTable[3].DefaultData = L"";
> paramTable[3].DefaultLength = 0;
>
> This is the last entry in the paramTable. The values at
paramTable[4]
> are all zero’ed.
>
> If the REG_EXPAND_SZ value does not contain any environment
variables
> everything works fine. RtlQueryRegistryValues returns the
string in
> my supplied unicode buffer (fpgaFileName). However, if the
registry
> value contains an environment varialbe (%SystemRoot% for example) I
> get the blue screen below.
>
> The problem appears that RtlQueryEnvironmentVariable_U is
either not
> loaded in memory or has the wrong address. I verified that I am
> running at IRQL Passive Level.
>
> Does anyone have any ideas what I might be doing wrong?
>
> - Steve -
>
>
> 0: kd> !analyze -v
> **************************************************************
> **********
> ****
> ***
> *
> *
> * Bugcheck Analysis
> *
> *
> *
> **************************************************************
> **********
> ****
> ***
>
> PAGE_FAULT_IN_NONPAGED_AREA (50)
> Invalid system memory was referenced. This cannot be protected by
> try-except, it must be protected by a Probe. Typically the
address is
> just plain bad or it is pointing at freed memory.
> Arguments:
> Arg1: 80681cb4, memory referenced.
> Arg2: 00000000, value 0 = read operation, 1 = write operation.
> Arg3: 80681cb4, If non-zero, the instruction address which
referenced
> the bad memory
> address.
> Arg4: 00000000, (reserved)
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: 80681cb4
>
> FAULTING_IP:
> nt!RtlQueryEnvironmentVariable_U+0
> 80681cb4 ?? ???
>
> MM_INTERNAL_CODE: 0
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x50
>
> LAST_CONTROL_TRANSFER: from 804f428c to 8051d4b0
>
> STACK_TEXT:
> fc9172fc 804f428c 00000003 804d4000 80681cb4
> nt!RtlpBreakWithStatusInstruction
> fc917348 804f4d11 00000003 806bb8cc c0201a04
> nt!KiBugCheckDebugBreak+0x19
> fc917714 804f52af 00000050 80681cb4 00000000 nt!KeBugCheck2+0x46d
> fc917734 8051445e 00000050 80681cb4 00000000 nt!KeBugCheckEx+0x19
> fc917784 80532fa8 00000000 80681cb4 00000000 nt!MmAccessFault+0x758
> fc917784 80681cb4 00000000 80681cb4 00000000
nt!KiTrap0E+0xbc fc91780c
> 805c5f92 00000000 fc917834 fc91782c
nt!RtlQueryEnvironmentVariable_U
> fc91784c 805c66de 00000000 00000082 fc917878
> nt!RtlExpandEnvironmentStrings_U+0xb6
> fc917890 805c6ade fc917970 e1dc2604 fc9178f0
> nt!RtlpCallQueryRegistryRoutine+0x2db
> fc9178f4 f772965d 00000000 00000084 00000001
> nt!RtlQueryRegistryValues+0x2a4
> fc9179c4 f77255dd 00000064 f7730018 81255e40
> fg8000!cfFg8000GetDeviceParamsFromRegistry+0x17b
> [c:/fg8000/entrycom.c @
> 494]
> fc9179f4 804f2a40 ff9de2d0 81255e40 00000000
> fg8000!cfFg8000AddDevice+0xdf [c:/fg8000/pnp.c @ 166] fc917a10
> 80574afe f77254fe 00000004 00000001 nt!PpvUtilCallAddDevice+0x2c
> fc917ad8 80575d29 00000000 02000001 00000000
> nt!PipCallDriverAddDevice+0x374
> fc917d24 8057620e 81255738 00000001 00000000
> nt!PipProcessDevNodeTree+0x147
> fc917d54 804f2120 00000003 805482c0 8054d0dc
nt!PiRestartDevice+0x7e
> fc917d7c 80528267 00000000 00000000 81275b30
> nt!PipDeviceActionWorker+0x15a fc917dac 805b046c 00000000 00000000
> 00000000 nt!ExpWorkerThread+0xed fc917ddc 80534ad6 8052817a
00000001
> 00000000 nt!PspSystemThreadStartup+0x34 00000000 00000000 00000000
> 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> FAILED_INSTRUCTION_ADDRESS:
> nt!RtlQueryEnvironmentVariable_U+0
> 80681cb4 ?? ???
>
> FOLLOWUP_IP:
> fg8000!cfFg8000GetDeviceParamsFromRegistry+17b
> f772965d ff75f4 push dword ptr [ebp-0xc]
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: fg8000!cfFg8000GetDeviceParamsFromRegistry+17b
>
> MODULE_NAME: fg8000
>
> IMAGE_NAME: fg8000.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 3ea5d39a
>
> STACK_COMMAND: kb
>
> BUCKET_ID:
> 0x50_CODE_AV_BAD_IP_fg8000!cfFg8000GetDeviceParamsFromRegistry+17b
>
> Followup: MachineOwner
> ---------
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@microsoft.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@cognex.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>

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

6

I thought that a bugcheck was a bit harsh and I find it strange that the
RtlQueryEnvironmentVariable_U function address was unreadable (I assume it
wasn’t loaded but I’m not sure why it didn’t get loaded since the system was
at PASSIVE_LEVEL).

I have already changed my code to use a REG_SZ string and make it a
requirement that the data can’t be an environment variable.

  • Steve -

-----Original Message-----
From: Mark Roddy [mailto:xxxxx@hollistech.com]
Sent: Thursday, April 24, 2003 9:04 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with RtlQueryRegistryValues

> Thanks for the information. The DDK doc didn’t provide any
information
> that
> REG_EXPAND_SZ could only be used in the context of another process.
> The
> docs even provide information about REG_EXPAND_SZ so I
thought it would
> be
> alright to us it.
>

However, the call should not bugcheck, so while environment expansion
might not work, it does not explain the system crash.

===========================
Mark Roddy
Consultant, Microsoft DDK MVP
Hollis Technology Solutions
xxxxx@hollistech.com
www.hollistech.com
603-321-1032

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

7

The problem is the DDK does document REG_EXPAND_SZ. It tells you how to
fill in the RTL_QUERY_REGISTRY_TABLE structure and even has some flags that
let you decide if you want the REG_EXPAND_SZ to be processed or passed back
unchanged. Silly me for expecting it to work.

  • Steve -

-----Original Message-----
From: Peter Wieland [mailto:xxxxx@windows.microsoft.com]
Sent: Thursday, April 24, 2003 11:58 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with RtlQueryRegistryValues

the registry is the “system environment variables” :slight_smile:

the safest approach to take with the DDK is to assume that
it’s not safe
to use unless it is documented. It’s very hard to document
everything a
driver shouldn’t do.

-p
>
> -----Original Message-----
> From: Whitman, Steve [mailto:xxxxx@cognex.com]
> Sent: Thursday, April 24, 2003 5:37 AM
> To: NT Developers Interest List
>
> Thanks for the information. The DDK doc didn’t provide any
> information that REG_EXPAND_SZ could only be used in the
> context of another process. The docs even provide
> information about REG_EXPAND_SZ so I thought it would be
> alright to us it.
>
> BTW, I didn’t think I would be able to get user environment
> variables but I thought that the “system” environment
> variables would be available.
>
> - Steve -
>
> > -----Original Message-----
> > From: Peter Wieland [mailto:xxxxx@windows.microsoft.com]
> > Sent: Wednesday, April 23, 2003 3:14 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: Problem with RtlQueryRegistryValues
> >
> >
> > Environment variables are a user-mode per-process thing
(stored off
> > the PEB). There’s really no concept of system environment
> variables.
> >
> > So you might be able to get them from the calling process
> in an IOCTL
> > (though I’d be surprised) but you can’t get at them during PNP
> > operations, from system threads, or other times when you’re
> not in the
> > client process address space.
> >
> > -p
> >
> >
> > This posting is provided “AS IS” with no warranties, and
confers no
> > rights
> >
> >
> >
> > -----Original Message-----
> > From: Whitman, Steve [mailto:xxxxx@cognex.com]
> > Sent: Wednesday, April 23, 2003 12:01 PM
> > To: NT Developers Interest List
> >
> > I have been using the RtlQueryRegistryValues function to read
> > REG_DWORD values from the registry. Now I need to read a
> > REG_EXPAND_SZ value. I reviewed the DDK documentation
(the online
> > version) and I believe I have set the RTL_QUERY_REGISTRY_TABLE up
> > correctly.
> > paramTable[3].Flags = RTL_QUERY_REGISTRY_DIRECT;
> > paramTable[3].Name = L"FPGAFileName";
> > paramTable[3].EntryContext = fpgaFileName; // Pointer to
> > UNICODE_STRING
> > paramTable[3].DefaultType = REG_EXPAND_SZ;
> > paramTable[3].DefaultData = L"";
> > paramTable[3].DefaultLength = 0;
> >
> > This is the last entry in the paramTable. The values at
> paramTable[4]
> > are all zero’ed.
> >
> > If the REG_EXPAND_SZ value does not contain any environment
> variables
> > everything works fine. RtlQueryRegistryValues returns the
> string in
> > my supplied unicode buffer (fpgaFileName). However, if the
> registry
> > value contains an environment varialbe (%SystemRoot% for
example) I
> > get the blue screen below.
> >
> > The problem appears that RtlQueryEnvironmentVariable_U is
> either not
> > loaded in memory or has the wrong address. I verified that I am
> > running at IRQL Passive Level.
> >
> > Does anyone have any ideas what I might be doing wrong?
> >
> > - Steve -
> >
> >
> > 0: kd> !analyze -v
> > **************************************************************
> > **********
> > ****
> > ***
> > *
> > *
> > * Bugcheck Analysis
> > *
> > *
> > *
> > **************************************************************
> > **********
> > ****
> > ***
> >
> > PAGE_FAULT_IN_NONPAGED_AREA (50)
> > Invalid system memory was referenced. This cannot be
protected by
> > try-except, it must be protected by a Probe. Typically the
> address is
> > just plain bad or it is pointing at freed memory.
> > Arguments:
> > Arg1: 80681cb4, memory referenced.
> > Arg2: 00000000, value 0 = read operation, 1 = write operation.
> > Arg3: 80681cb4, If non-zero, the instruction address which
> referenced
> > the bad memory
> > address.
> > Arg4: 00000000, (reserved)
> >
> > Debugging Details:
> > ------------------
> >
> >
> > READ_ADDRESS: 80681cb4
> >
> > FAULTING_IP:
> > nt!RtlQueryEnvironmentVariable_U+0
> > 80681cb4 ?? ???
> >
> > MM_INTERNAL_CODE: 0
> >
> > DEFAULT_BUCKET_ID: DRIVER_FAULT
> >
> > BUGCHECK_STR: 0x50
> >
> > LAST_CONTROL_TRANSFER: from 804f428c to 8051d4b0
> >
> > STACK_TEXT:
> > fc9172fc 804f428c 00000003 804d4000 80681cb4
> > nt!RtlpBreakWithStatusInstruction
> > fc917348 804f4d11 00000003 806bb8cc c0201a04
> > nt!KiBugCheckDebugBreak+0x19
> > fc917714 804f52af 00000050 80681cb4 00000000 nt!KeBugCheck2+0x46d
> > fc917734 8051445e 00000050 80681cb4 00000000 nt!KeBugCheckEx+0x19
> > fc917784 80532fa8 00000000 80681cb4 00000000
nt!MmAccessFault+0x758
> > fc917784 80681cb4 00000000 80681cb4 00000000
> nt!KiTrap0E+0xbc fc91780c
> > 805c5f92 00000000 fc917834 fc91782c
> nt!RtlQueryEnvironmentVariable_U
> > fc91784c 805c66de 00000000 00000082 fc917878
> > nt!RtlExpandEnvironmentStrings_U+0xb6
> > fc917890 805c6ade fc917970 e1dc2604 fc9178f0
> > nt!RtlpCallQueryRegistryRoutine+0x2db
> > fc9178f4 f772965d 00000000 00000084 00000001
> > nt!RtlQueryRegistryValues+0x2a4
> > fc9179c4 f77255dd 00000064 f7730018 81255e40
> > fg8000!cfFg8000GetDeviceParamsFromRegistry+0x17b
> > [c:/fg8000/entrycom.c @
> > 494]
> > fc9179f4 804f2a40 ff9de2d0 81255e40 00000000
> > fg8000!cfFg8000AddDevice+0xdf [c:/fg8000/pnp.c @ 166] fc917a10
> > 80574afe f77254fe 00000004 00000001 nt!PpvUtilCallAddDevice+0x2c
> > fc917ad8 80575d29 00000000 02000001 00000000
> > nt!PipCallDriverAddDevice+0x374
> > fc917d24 8057620e 81255738 00000001 00000000
> > nt!PipProcessDevNodeTree+0x147
> > fc917d54 804f2120 00000003 805482c0 8054d0dc
> nt!PiRestartDevice+0x7e
> > fc917d7c 80528267 00000000 00000000 81275b30
> > nt!PipDeviceActionWorker+0x15a fc917dac 805b046c 00000000
00000000
> > 00000000 nt!ExpWorkerThread+0xed fc917ddc 80534ad6 8052817a
> 00000001
> > 00000000 nt!PspSystemThreadStartup+0x34 00000000 00000000
00000000
> > 00000000 00000000 nt!KiThreadStartup+0x16
> >
> >
> > FAILED_INSTRUCTION_ADDRESS:
> > nt!RtlQueryEnvironmentVariable_U+0
> > 80681cb4 ?? ???
> >
> > FOLLOWUP_IP:
> > fg8000!cfFg8000GetDeviceParamsFromRegistry+17b
> > f772965d ff75f4 push dword ptr [ebp-0xc]
> >
> > FOLLOWUP_NAME: MachineOwner
> >
> > SYMBOL_NAME: fg8000!cfFg8000GetDeviceParamsFromRegistry+17b
> >
> > MODULE_NAME: fg8000
> >
> > IMAGE_NAME: fg8000.sys
> >
> > DEBUG_FLR_IMAGE_TIMESTAMP: 3ea5d39a
> >
> > STACK_COMMAND: kb
> >
> > BUCKET_ID:
> > 0x50_CODE_AV_BAD_IP_fg8000!cfFg8000GetDeviceParamsFromRegistry+17b
> >
> > Followup: MachineOwner
> > ---------
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as:
xxxxx@microsoft.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@cognex.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@microsoft.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>

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