Tech Support > Microsoft Windows > Drivers > Verifier.exe is not compatible with RtlRandom(Ex)
Verifier.exe is not compatible with RtlRandom(Ex)
Posted by leo on October 9th, 2007


C:\Windows\System32\Verifier.exe is a Driver Verifier installed with windows
system.

In my own driver, I need use RtlRandom(Ex) function to generate random
integer.
But when I use Verifier.exe to check the robustness of my driver. The system
always crash down when the driver executes RtlRandom(Ex).

the cause reported in blue screen is IRQL_NOT_LESS_OR_EQUAL.

the following are the analyze result in windbg
================================================== ==
FAULTING_MODULE: 804d7000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 470aecc3

WRITE_ADDRESS: 805e7bd4

CURRENT_IRQL: 2

FAULTING_IP:
nt!RtlRandom+0
805e7bd4 8bff mov edi,edi

DEFAULT_BUCKET_ID: WRONG_SYMBOLS

BUGCHECK_STR: 0xA

LAST_CONTROL_TRANSFER: from 805e7bd4 to 80543930

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be
wrong.
f816f1dc 805e7bd4 badb0d00 819b8e30 00000000 nt!Kei386EoiHelper+0x2834
f816f258 f9aae000 f816f28c f9aad61f 819b8e30 nt!RtlRandom
f816f260 f9aad61f 819b8e30 00000000 81540740
passthru!PacketFilterDiscardPacket+0x50
[d:\project\mbus\src\tools\packet_filter\windows\dr iver\filter.c @ 49]
f816f28c bad7cff2 819b8e30 81540740 815407d0 passthru!PtReceive+0x4f
[d:\project\mbus\src\tools\packet_filter\windows\dr iver\protocol.c @ 974]
f816f2f4 bad6fec4 c000009a f816f314 00000001
NDIS!FddiFilterDprIndicateReceive+0xdfa
f816f31c bad5a99d 815e4ea0 00000103 81642130 NDIS!NdisRequest+0x559
f816f338 f9aab7d3 81651c50 815e4ed8 815e4ea0
NDIS!NdisDprFreePacketNonInterlocked+0x1c8
f816f37c bad5cf86 819b8e30 f816f3b0 00000001 passthru!MPSendPackets+0x163
[d:\project\mbus\src\tools\packet_filter\windows\dr iver\miniport.c @ 471]
f816f3a4 f8459454 816058e8 815e4ed8 815dfa58 NDIS!NdisInitializeString+0x6d1
f816f3c8 f84594f8 005dfa0e ff50a8c0 815e4ed8 tcpip!IPTransmit+0x2816
f816f3f4 f845770a 815dfa58 f816f400 00000001 tcpip!ARPRcv+0x85
f816f424 f84574a9 815b53f8 ff50a8c0 815e4ed8 tcpip!IPTransmit+0xacc
f816f570 f845bb83 f84956b4 816dee68 8153c020 tcpip!IPTransmit+0x86b
f816f610 f845b94a 815b6cd0 816dee68 81fccf48 tcpip!ARPRcv+0x2710
f816f634 f845b9b0 0016f658 815b3470 8153c060 tcpip!ARPRcv+0x24d7
f816f66c f845a308 81fccf48 81fccfdc 81608260 tcpip!ARPRcv+0x253d
f816f688 804ef095 81608260 81fccf48 806e4428 tcpip!ARPRcv+0xe95
f816f6bc f842e544 815b33a0 815ad8b8 f844798c nt!IoBuildPartialMdl+0xed
f816f6e0 f842e391 f816f708 815b3470 00000044 netbt+0x2544
f816f724 f8432149 815b33a0 c0a850ff 00000044 netbt+0x2391
f816f76c f8436421 815b33a0 815add58 005bc2f8 netbt+0x6149
f816f7bc f8436deb 00000000 00000000 815418cb netbt+0xa421
f816f818 f844987d f816f844 005418c5 c0a85083 netbt+0xadeb
f816f858 f84497f1 81691620 81fb4f48 0000001a netbt+0x1d87d
f816f878 804ef095 81691620 00fb4f48 806e4428 netbt+0x1d7f1
f816f8ac 80581f6e 81627748 815c6238 f816fa7c nt!IoBuildPartialMdl+0xed
f816f98c 80582390 81691620 00000000 815bf8b0 nt!NtWriteFile+0x6278
f816f9c4 805bd99d 81627748 00000000 815bf8b0 nt!NtWriteFile+0x669a
f816fa3c 805ba448 00000448 f816fa7c 00000040 nt!NtMakePermanentObject+0xd8f
f816fa90 80574ec1 00000000 00000000 52c1bb00 nt!ObOpenObjectByName+0xea
f816fb0c 80575838 815a3f44 c0100000 f816fc8c nt!IoCreateDevice+0x74b
f816fb68 80577f02 815a3f44 c0100000 f816fc8c nt!IoCreateFile+0x8e
f816fba8 8054086c 815a3f44 c0100000 f816fc8c nt!NtCreateFile+0x30
f816fbdc 804ff549 badb0d00 f816fc54 00000000
nt!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb7 4
f816fcb0 f8358094 815a3f04 e17c7188 815a3f2c nt!ZwCreateFile+0x11
f816fcec f82e743d 815a3f2c 815a3f04 f816fd28 rdbss!RxCeBuildAddress+0xb1
f816fd50 f82e82ee e17d3f80 f816fd6c f834258e mrxsmb+0x3343d
f816fd5c f834258e e17d3f80 f8348ec0 f816fd9c mrxsmb+0x342ee
f816fd6c f833f4b1 815450b8 00000000 81540da8
rdbss!RxDispatchToWorkerThread+0xa1
f816fd9c f8349845 00348ec0 f8349140 f816fddc rdbss+0x4b1
f816fdac 805ce84c f8348ec0 00000000 00000000
rdbss!RxpReleasePrefixTableLock+0x54
f816fddc 8054532e f834982b f8348ec0 00000000
nt!PsRemoveCreateThreadNotifyRoutine+0x214
00000000 00000000 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x72e
===================================

if RtlRandom(Ex) should be executed in LOWER IRQL, what can I do?

Posted by Eliyas Yakub [MSFT] on October 9th, 2007


RtlRandom(Ex) can be called only at PASSIVE_LEVEL. When you turn on
verifier, it is raising IRQL to DISPATCH_LEVEL to see if you can handle
that.

-Eliyas

"leo" <leo@discussions.microsoft.com> wrote in message
news:F1A79AC0-48D5-46C1-8A86-AE4311C70B7E@microsoft.com...

Posted by leo on October 9th, 2007


Eliyas,
Thanks for your reply.
My Driver need a random function called at DISPATCH_LEVEL, and it
should give me good stochastic simulation. Though RtlRandom(Ex) should be
only called at PASSIVE_LEVEL, does any other API provided by microsoft or
others third party satisfy my reqirement?

"Eliyas Yakub [MSFT]" wrote:

Posted by Maxim S. Shatskih on October 9th, 2007


Write your own pseudo-random code.

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

"leo" <leo@discussions.microsoft.com> wrote in message
news:B16426DF-56D9-4133-B185-E8E46AB3B313@microsoft.com...

Posted by Eliyas Yakub [MSFT] on October 9th, 2007


I couldn't find another random generator interface in the kernel that can be
called at DISPATCH_LEVEL. For my test drivers, I just use my own
pseudo-random generator code.

-Eliyas


Similar Posts