Re: Unknown Wdf01000.sys error

Tech-Archive recommends: Fix windows errors by optimizing your registry

Thanks, Doron,

Here is a part of message from the original one. Does it mean the
problem is coming from collections?


82bb7888 807073a0 850ce370 8502b624 8502b624 Wdf01000!
FxCollectionInternal::CleanupEntryObject+0x19
82bb789c 807073fc 84ff17e0 8502b628 82bb78d4 Wdf01000!
FxCollectionInternal::RemoveEntry+0x13
82bb78ac 80707421 00000000 8502b624 8502b5f0 Wdf01000!
FxCollectionInternal::Remove+0x1c
82bb78bc 807074b6 8502b5f0 8502b5f0 806eaa89 Wdf01000!
FxCollectionInternal::Clear+0x14
82bb78c8 806eaa89 8502b5f0 82bb78f4 806a7d13 Wdf01000!
FxCollection::~FxCollection+0x16


I always use WDFMEMORY object to allocate memory and use
WdfObjectDelete to free that kind of memory.

This problem is hard to reproduce. I will try again. Thanks for your
information. ^_^

Ziv


On 4月23日, 上午1?21分, "Doron Holan [MSFT]" <dor...@xxxxxxxxxxxxxxxxxxxx>
wrote:
my guess is that you freed a pointer that is not yours or you corrupted
memory.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights..

"泛若不?舟" <ZivHu...@xxxxxxxxx> wrote in message

news:ed8be3f4-68de-440b-a010-22bc49f386d0@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx



Hi all,

I encounter a bugcheck when disabling my driver. I don't known why
because all the stack isn't in my driver. @@

Thanks.

-----------------------------------------------------------------------------------

Use !analyze -v to get detailed debugging information.

BugCheck D1, {d06, 2, 1, 806d37fc}

Probably caused by : Wdf01000.sys ( Wdf01000!FxPoolFree+8d )

Followup: MachineOwner
---------

nt!RtlpBreakWithStatusInstruction:
81881760 cc int 3
0: kd> !analyze -v
***************************************************************************-****
*
*
* Bugcheck
Analysis *
*
*
***************************************************************************-****

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid)
address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 00000d06, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 806d37fc, address which referenced memory

Debugging Details:
------------------

WRITE_ADDRESS: 00000d06

CURRENT_IRQL: 2

FAULTING_IP:
Wdf01000!FxPoolFree+8d
806d37fc 897904 mov dword ptr [ecx+4],edi

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: System

TRAP_FRAME: 82bb77a4 -- (.trap 0xffffffff82bb77a4)
ErrCode = 00000002
eax=00000000 ebx=00000000 ecx=00000d02 edx=00000000 esi=850ce330
edi=850d07a8
eip=806d37fc esp=82bb7818 ebp=82bb7824 iopl=0 nv up ei pl zr
na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
Wdf01000!FxPoolFree+0x8d:
806d37fc 897904 mov dword ptr [ecx+4],edi ds:
0023:00000d06=????????
Resetting default scope

LAST_CONTROL_TRANSFER: from 818d873f to 81881760

STACK_TEXT:
82bb7384 818d873f 00000003 82bbc894 00000000 nt!
RtlpBreakWithStatusInstruction
82bb73d4 818d91ac 00000003 00000d06 806d37fc nt!KiBugCheckDebugBreak
+0x1c
82bb7784 8188fc44 0000000a 00000d06 00000002 nt!KeBugCheck2+0x5f4
82bb7784 806d37fc 0000000a 00000d06 00000002 nt!KiTrap0E+0x2ac
82bb7824 806ce9eb 850ce358 82bb7840 806e084f Wdf01000!FxPoolFree+0x8d
82bb7830 806e084f 850ce370 850ce370 82bb7860 Wdf01000!
FxObject::operator delete+0x13
82bb7840 806a7d13 00000001 806d48ea 00000000 Wdf01000!
FxMemoryPagedBufferFromPool::`vector deleting destructor'+0x19
82bb7848 806d48ea 00000000 00000000 00000000 Wdf01000!
FxObject::SelfDestruct+0xb
82bb7860 806cef06 8502b624 84ff17e0 82bb7888 Wdf01000!
FxObject::ProcessDestroy+0x9f
82bb7870 80705c19 8502b624 0000007a 00000000 Wdf01000!FxObject::Release
+0x10c
82bb7888 807073a0 850ce370 8502b624 8502b624 Wdf01000!
FxCollectionInternal::CleanupEntryObject+0x19
82bb789c 807073fc 84ff17e0 8502b628 82bb78d4 Wdf01000!
FxCollectionInternal::RemoveEntry+0x13
82bb78ac 80707421 00000000 8502b624 8502b5f0 Wdf01000!
FxCollectionInternal::Remove+0x1c
82bb78bc 807074b6 8502b5f0 8502b5f0 806eaa89 Wdf01000!
FxCollectionInternal::Clear+0x14
82bb78c8 806eaa89 8502b5f0 82bb78f4 806a7d13 Wdf01000!
FxCollection::~FxCollection+0x16
82bb78d4 806a7d13 00000001 806d48ea 00000000 Wdf01000!
FxIoResReqList::`vector deleting destructor'+0xd
82bb78dc 806d48ea 00000000 00000000 00000000 Wdf01000!
FxObject::SelfDestruct+0xb
82bb78f4 806cef06 8502b604 8502b5f0 82bb7924 Wdf01000!
FxObject::ProcessDestroy+0x9f
82bb7904 806d4ade 00000000 00000465 00000000 Wdf01000!FxObject::Release
+0x10c
82bb7924 806d4bb8 8502b500 8514ac68 8514ac84 Wdf01000!
FxObject::DeletedAndDisposedWorkerLocked+0xe1
82bb793c 806d4ac5 850afd74 8514ac68 82bb7964 Wdf01000!
FxObject::ParentDeleteEvent+0xcf
82bb794c 806d4bb8 8514ac00 850afd60 850afd7c Wdf01000!
FxObject::DeletedAndDisposedWorkerLocked+0xc8
82bb7964 806d4ac5 8512488c 850afd60 82bb798c Wdf01000!
FxObject::ParentDeleteEvent+0xcf
82bb7974 806d4bb8 850afd00 850baaa8 00000124 Wdf01000!
FxObject::DeletedAndDisposedWorkerLocked+0xc8
82bb798c 806f491a 00000008 850baaa8 806f3387 Wdf01000!
FxObject::ParentDeleteEvent+0xcf
82bb7998 806f3387 806f4551 82bb79cc 806f4fec Wdf01000!
FxPkgPnp::PnpEventRemovedCommonCode+0xf8
82bb799c 806f4551 82bb79cc 806f4fec 850baaa8 Wdf01000!
FxPkgFdo::PnpEventFdoRemovedOverload+0x5
82bb79a4 806f4fec 850baaa8 8070e380 850baaa8 Wdf01000!
FxPkgPnp::PnpEventFdoRemoved+0xd
82bb79cc 806f5d40 00000117 850bab48 850baaa8 Wdf01000!
FxPkgPnp::PnpEnterNewState+0x15c
82bb79f4 806f606d 82bb7a0c 00000000 850baaa8 Wdf01000!
FxPkgPnp::PnpProcessEventInner+0x1f5
82bb7a1c 806ee774 00000200 850baaa8 8070d8a0 Wdf01000!
FxPkgPnp::PnpProcessEvent+0x1cf
82bb7a44 806edb83 850baaa8 82bb7a64 a193af20 Wdf01000!
FxPkgPnp::_PnpRemoveDevice+0x69
82bb7a68 806d7665 a193af20 82bb7a90 806d786a Wdf01000!
FxPkgPnp::Dispatch+0x2a6
82bb7a74 806d786a 84f904e8 a193af20 a193af20 Wdf01000!
FxDevice::Dispatch+0x7f
82bb7a90 81ace681 84f904e8 a193af20 86b11b38 Wdf01000!
FxDevice::DispatchWithLock+0x5d
82bb7ab4 81827e86 8a7035a5 85169498 84f904e8 nt!IovCallDriver+0x252
82bb7ac8 8a7035a5 85169498 82bb7af0 8a703a0e nt!IofCallDriver+0x1b
WARNING: Stack unwind information not available. Following frames may
be wrong.
82bb7ad4 8a703a0e 851693e0 a193af20 a193af20 pnpfiltr+0x5a5
82bb7af0 8a7055ff 851693e0 a193af20 a193af20 pnpfiltr+0xa0e
82bb7b08 81ace681 851693e0 a193af20 a193affc pnpfiltr+0x25ff
82bb7b2c 81827e86 819af4a9 82bb7bcc 851693e0 nt!IovCallDriver+0x252
82bb7b40 819af4a9 851041d8 850b6bf8 851041d8 nt!IofCallDriver+0x1b
82bb7b74 819af70f 851041d8 82bb7ba8 00000000 nt!IopSynchronousCall
+0xce
82bb7bd0 81806561 851041d8 00000002 a68acaf8 nt!IopRemoveDevice+0xd5
82bb7bfc 819a5ced 00000000 a68acaf8 00000000 nt!
PnpRemoveLockedDeviceNode+0x172
82bb7c14 819a5f67 00000000 00000000 00000000 nt!
PnpDeleteLockedDeviceNode+0x2b
82bb7c44 819aa8d8 8546d700 a68acaf8 00000002 nt!
PnpDeleteLockedDeviceNodes+0x4c
82bb7d04 819aac2b 82bb7d34 00000000 a68b1b78 nt!
PnpProcessQueryRemoveAndEject+0x8ac
82bb7d1c 819a9793 00000000 818fde3c 846fc828 nt!
PnpProcessTargetDeviceEvent+0x38
82bb7d44 81878e18 84f75760 00000000 846fc828 nt!PnpDeviceEventWorker
+0x201
82bb7d7c 81a254a8 84f75760 82bbc680 00000000 nt!ExpWorkerThread+0xfd
82bb7dc0 8189145e 81878d1b 00000001 00000000 nt!PspSystemThreadStartup
+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
Wdf01000!FxPoolFree+8d
806d37fc 897904 mov dword ptr [ecx+4],edi

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: Wdf01000!FxPoolFree+8d

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Wdf01000

IMAGE_NAME: Wdf01000.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 474f6583

FAILURE_BUCKET_ID: 0xD1_W_VRF_Wdf01000!FxPoolFree+8d

BUCKET_ID: 0xD1_W_VRF_Wdf01000!FxPoolFree+8d

Followup: MachineOwner
---------- ?藏被引用文字 -

- ?示被引用文字 -

.

Relevant Pages

  • Re: If Macs have no spyware....
    ... >had made a complete code review of its operating system and removed all ... and writing new data into those memory locations would ... >but when the data exists on the stack, it can cause very large problems. ... >location that needs to be written in place of the correct execution ...
    (comp.sys.mac.advocacy)
  • Re: If Macs have no spyware....
    ... First you yammer about being a Mac advocate, then bad mouth me for dumping XP in favor of a Mac. ... Supposedly Microsoft had made a complete code review of its operating system and removed all the buffers which could overflow. ... the fundamental problem is that the basic architecture of Windows has two fatal flaws in its memory management and while these remain in the software the ad hoc patches will never be enough to make Windows a secure operating system. ... These problems are bad enough when dealing with data in the one routine but when the data exists on the stack, it can cause very large problems. ...
    (comp.sys.mac.advocacy)
  • Re: Maybe we should stop "Paging Beth Stone" already...
    ... I'll want to work on my OS while running my OS, so the assembler that it's written with has to run under it. ... You have to swap CR3 if you want seperate memory spaces. ... The alternate stacks aren't used by the processor unless the task calls a different protection level, so they're not part of the TSS swap. ... This lets any application use up to a gigabyte of stack before Linux is forced to tell it that it's gone too far. ...
    (alt.lang.asm)
  • Re: When is "volatile" used instead of "lock" ?
    ... to get the address of a stack variable to a background thread. ... I'm suggesting that the memory model ... lock pattern works without making the instance member volatile; ... fields shared amongst more than one thread despite following the locking ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Resolving internal links
    ... You have to pass all workspace in via ... Which highlights another issue - you could not use Fortify (or similar code which uses these functions to replace the memory allocators) within the main application code unless you also used it within the module. ... At best you'll reference memory which does not exist and cause an abort. ... will only be able to use 256 bytes of stack space IIRC. ...
    (comp.sys.acorn.programmer)