Main Page Windows 7 DLLs NirSoft Utilities
Windows 10 DLL File Information - verifier.dll

The following DLL report was generated by automatic DLL script that scanned and loaded all DLL files in the system32 directory of Windows 10, extracted the information from them, and then saved it into HTML reports. If you want to view a report of another DLL, go to the main page of this Web site.

 

General Information

File Description: Standard application verifier provider dll  
File Version: 10.0.10130.0 (fbl_impressive.150522-2224)  
Company: Microsoft Corporation  
Product Name: Microsoft® Windows® Operating System  
DLL popularity Very Low - There is no any other DLL in system32 directory that is statically linked to this file.
File Size: 342 KB
Total Number of Exported Functions: 26
Total Number of Exported Functions With Names: 26
 

Section Headers

Name Virtual Address Raw Data Size % of File Characteristics Section Contains...
.text 0x00001000 164,864 Bytes 47.0% Read, Execute Code
.data 0x0002a000 22,528 Bytes 6.4% Write, Read Initialized Data
.idata 0x0003b000 4,608 Bytes 1.3% Read Initialized Data
.rsrc 0x0003d000 135,168 Bytes 38.5% Read Initialized Data
.reloc 0x0005e000 10,752 Bytes 3.1% Read, Discardable Initialized Data
 

Static Linking

verifier.dll is statically linked to the following files:

ntdll.dll

This means that when verifier.dll is loaded, the above files are automatically loaded too. If one of these files is corrupted or missing, verifier.dll won't be loaded.

 

General Resources Information

Resource Type Number of Items Total Size % of File
Icons 0 0 Bytes 0.0%
Animated Icons 0 0 Bytes 0.0%
Cursors 0 0 Bytes 0.0%
Animated Cursors 0 0 Bytes 0.0%
Bitmaps 0 0 Bytes 0.0%
AVI Files 0 0 Bytes 0.0%
Dialog-Boxes 0 0 Bytes 0.0%
HTML Related Files 0 0 Bytes 0.0%
Menus 0 0 Bytes 0.0%
Strings 689 129,842 Bytes 37.0%
Type Libraries 0 0 Bytes 0.0%
Manifest 0 0 Bytes 0.0%
All Others 1 968 Bytes 0.3%
Total 690 130,810 Bytes 37.3%
 

Icons in this file

No icons found in this file

 

Cursors in this file

No cursors found in this file

 

Dialog-boxes list (up to 1000 dialogs)

No dialog resources in this file.

 

String resources in this dll (up to 1000 strings)

String ID String Text
60 AVRF: Terminate process after verifier stop failed with %X
61 This verifier stop is not continuable. Process will be terminated when you use the `go' debugger command.
62 This verifier stop is continuable. After debugging it use `go' to continue.
63 AVRF: Formatting message failed in VerifierStopMessageEx
64 AVRF: Noncontinuable verifier stop %p encountered. Terminating process ...
65 ======================================= VERIFIER STOP %p: pid 0x%X: %S %p : %S %p : %S %p : %S %p : %S %S ======================================= %S =======================================
66 ======================================= VERIFIER STOP %p: pid 0x%X: %s %p : %s %p : %s %p : %s %p : %s %s ======================================= %s =======================================
100 Full
101 Dlls
102 Size
103 SizeStart
104 SizeEnd
105 RandRate
106 Backward
107 Unalign
108 Traces
109 Protect
110 NoSync
111 NoLock
112 Faults
113 FaultRate
114 TimeOut
115 Addr
116 AddrStart
117 AddrEnd
118 Random
200 TRUE for full page heap. FALSE for normal page heap.
201 Page heap allocations for target dlls only. Name of the binaries with extension (.dll or something else).
202 Page heap allocations for size range.
203 Beginning of the size range.
204 Ending of the size range.
205 Decimal integer in range [0..100] representing probability to make page heap allocation vs. a normal heap allocation.
206 Catch backwards overruns.
207 No alignment for allocations.
208 Collect stack traces
209 Protect heap internal structures. Can be used to detect random corruptions but execution is slower.
210 Check for unsynchronized access. Do not use this flag for an MPheap process.
211 Disable critical section verifier.
212 Fault injection
213 Probability (1..10000) for heap calls failures
214 Time during process initialization (in milliseconds) when faults are not allowed.
215 Page heap allocations for address range
216 Beginning of the address range
217 Ending of the address range
218 Page heap allocations with probability.
300 Failed within the address range where the specified dlls are loaded.
301 Doesn't fail within those dlls.
302 Grace period as Milliseconds.
303 Wait API.
304 Heap allocation.
305 Virtual memory allocation.
306 Registry API.
307 File API.
308 Event Manipulation.
309 Map View.
310 Ole API.
311 Disable automatic stack expansion.
350 DllMainCheck
351 Check LoadLibrary/FreeLibrary calling when DllMain is active
360 Traces
361 Maximum number of traces in the handle history buffer.
370 Delay
371 Delay until rollover in (seconds).
380 AsyncCheck
381 Check asynchronous calls that require a persistent thread
390 ExecWritePage
391 Checking the usage of executable and writable memory
392 FillReadBuffer
393 Fills I/O buffer with a pattern before initiating the I/O, to catch bugs around uninitialized buffers
394 ForcePendingIO
395 Probability in parts per million for forcing STATUS_PENDING in place of STATUS_SUCCESS
396 ExcludeDlls
397 Excludes these dlls (comma separated) from leak detection. Max size is 255 characters
400 Checks for errors in lock usage. This might cause access violations when errors are located. A debugger is required to see the test results.
401 Checks that applications and components use RPC correctly. Common mistakes and problems while using RPC are flagged. A debugger is required to see the test results.
402 Checks that applications and components use COM correctly. Common mistakes and problems while using COM are flagged. A debugger is required to see the test results.
403 Checks that applications and components use TLS (Thread Local Storage) APIs correctly. Common mistakes and problems while using TLS APIs are flagged. A debugger is required to see the test results.
404 Helps catch uninitialized variables
405 Detects first chance access violation exceptions. A debugger is required to see the test results.
406 Checks for handle errors. This might cause access violations when errors are located. A debugger is required to see the test results.
407 Checks the heap errors. A debugger is required to see the test results.
408 Checks for adequate stack size by stopping stack growth. This causes a stack overflow error if the original stack size is too small. You can prevent this from happening by increasing the stack commit size.
409 Checks usage of virtual memory APIs. A debugger is required to see the test results.
410 Checks usage of dangerous API usage.
411 Forces the GetTickCount API to roll over faster than they normally would. This allows applications to test their handling of timer rollover more easily.
412 Checks for dirty threadpool thread and other threadpool related issues.
413 Low Resource Simulation also known as Fault Injection, tries to simulate an environment under low resources, such as out of memory.
414 Checks issues related to I/O transfers.
415 Checks that when a dll is unloaded there are no outstanding resources allocated by it.
416 Checks for errors in SRW locks usage. Invalid SRW lock usage can result in application crashes or hangs. A debugger is required to see the test results.
3000 Dangerous call to TerminateThread.
3001 Thread ID for the caller of Terminatethread.
3002 Not used.
3003 Not used.
3004 Not used.
3006 This stop is generated if a thread (thread ID is parameter1) is terminated explicitly using TerminateThread.This function is very dangerous because it introduces data corruption and deadlocks (as per MSDN).
3010 Potential stack overflow in low memory conditions.
3011 Not used.
3012 Not used.
3013 Not used.
3014 Not used.
3016 This stop is generated if the initial stack commit size of a thread is such that a stack overflow can be raised in low memory conditions if stack cannot be extended.
3020 ExitProcess called while multiple threads still running.
3021 Number of threads running.
3022 Not used.
3023 Not used.
3024 Not used.
3026 This stop is generated if a thread calls ExitProcess while there are several threads running. In such a case, internally TerminateThread will be called for each thread and this can create deadlocks or data corruptions.
3030 LoadLibrary is called during DllMain.
3031 Dll Name (use du to dump).
3032 Dll base address.
3033 Not used.
3034 Not used.
3036 This stop is generated if the code inside DllMain calls LoadLibrary or FreeLibary. It's the behavior forbidden by MSDN.
3040 FreeLibrary is called during DllMain.
3041 Dll Name (use du to dump).
3042 Dll base address.
3043 Not used.
3044 Not used.
3046 This stop is generated if the code inside DllMain calls LoadLibrary or FreeLibary. It's the behavior forbidden by MSDN.
3050 SetProcessWorkingSetSize is called with MinimumWorkingSetSize = 0xFFFFFFFF.
3051 Not used.
3052 Not used.
3053 Not used.
3054 Not used.
3056 Please use MinimumWorkingSetSize = (SIZE_T) -1.
3060 SetProcessWorkingSetSize is called with MaximumWorkingSetSize = 0xFFFFFFFF.
3061 Not used.
3062 Not used.
3063 Not used.
3064 Not used.
3066 Please use MaximumWorkingSetSize = (SIZE_T) -1.
3070 SetProcessWorkingSetSizeEx is called with MinimumWorkingSetSize = 0xFFFFFFFF.
3071 Not used.
3072 Not used.
3073 Not used.
3074 Not used.
3076 Please use MinimumWorkingSetSize = (SIZE_T) -1.
3080 SetProcessWorkingSetSizeEx is called with MaximumWorkingSetSize = 0xFFFFFFFF.
3081 Not used.
3082 Not used.
3083 Not used.
3084 Not used.
3086 Please use MaximumWorkingSetSize = (SIZE_T) -1.
4000 Thread that is exiting owns a critical section.
4001 Thread ID of the thread that is exiting while owning a critical section.
4002 Critical section address. Run !cs -s <address> to get more information.
4003 Critical section debug information address.
4004 Critical section initialization stack trace. Run dps <address> to dump the stack trace.
4006 This stop is generated if a thread (thread ID is parameter1) is terminated, suspended or is in a state (worker thread finished a work item) in which it cannot hold a critical section. The current thread is the culprit. To debug this stop use the following debugger commands: $ kb - to get the current stack trace. If the current thread is the owner of the critical section it is probably calling ExitThread. The current thread should have released the critical section before exiting. If the current thread is calling TerminateThread or SuspendThread then it should not do this for a thread holding a critical section. $ !cs -s parameter2 - dump information about this critical section. $ ln parameter2 - to show symbols near the address of the critical section. This should help identify the leaked critical section. $ dps parameter4 - to dump the stack trace for this critical section initialization.
4010 Unloading DLL containing an active critical section.
4011 Critical section address. Run !cs -s <address> to get more information.
4012 Critical section initialization stack trace. Run dps <address> to dump the stack trace.
4013 DLL name address.
4014 DLL base address.
4016 This stop is generated if a DLL has a global variable containing a critical section and the DLL is unloaded but the critical section has not been deleted. To debug this stop use the following debugger commands: $ du parameter3 - to dump the name of the culprit DLL. $ .reload dllname or .reload dllname = parameter4 - to reload the symbols for that DLL. $ !cs -s parameter1 - dump information about this critical section. $ ln parameter1 - to show symbols near the address of the critical section. This should help identify the leaked critical section. $ dps parameter2 - to dump the stack trace for this critical section initialization.
4020 Freeing heap block containing an active critical section.
4021 Critical section address. Run !cs -s <address> to get more information.
4022 Critical section initialization stack trace. Run dps <address> to dump the stack trace.
4023 Heap block address.
4024 Heap block size.
4026 This stop is generated if a heap allocation contains a critical section, the allocation is freed and the critical section has not been deleted. To debug this stop use the following debugger commands: $ !cs -s parameter1 - dump information about this critical section. $ ln parameter1 - to show symbols near the address of the critical section. This should help identify the leaked critical section. $ dps parameter2 - to dump the stack trace for this critical section initialization. $ parameter3 and parameter4 might help understand where this heap block was allocated (the size of the allocation is probably significant).
4030 Double initialized or corrupted critical section.
4031 Critical section address. Run !cs -s <address> to get more information.
4032 Address of the debug information structure found in the active list.
4033 First initialization stack trace. Run dps <address> to dump the stack trace.
4034 Second initialization stack trace. Run dps <address> to dump the stack trace.
4036 Usually this stop is generated if a critical section has been initialized more than one time. In this case parameter3 and parameter4 are the stack trace addresses for two of these initializations. Some other times it is possible to get this stop if the critical section or its debug information structure has been corrupted. In this second case it is possible that parameter3 and parameter4 are invalid and useless. To debug this stop: $ !cs -s -d parameter2 - dump information about this critical section. $ ln parameter1 - to show symbols near the address of the critical section. This might help identify the critical section if this is a global variable. $ dps parameter3 and dps parameter4 - to identify the two code paths for initializing this critical section.
4040 Free memory containing an active critical section.
4041 Critical section address. Run !cs -s <address> to get more information.
4042 Critical section debug information address.
4043 Critical section initialization stack trace. Run dps <address> to dump the stack trace.
4044 Not used.
4046 This stop is generated if the memory containing a critical section was freed but the critical section has not been deleted using DeleteCriticalSection. To debug this stop use the following debugger commands: $ !cs -s -d parameter2 - dump information about this critical section. $ dps parameter3 - to identify the code path for initializing this critical section. In most cases the lock verifier detects immediately leaked critical sections contained in a heap allocation, a DLL range, a virtual memory allocation or a MapViewOfFile mapped memory range and issues different stops in these cases. So there are very few cases left for this verifier stop. The lock must be in a memory range freed by kernel-mode code or freed cross-process by APIs like VirtualFreeEx. Most typically this stop will be encountered if a previous stop (e.g. LOCK_IN_FREED_HEAP or LOCK_IN_UNLOADED_DLL) was continued by hitting `g' in the debugger console.
4050 Corrupted critical section.
4051 Critical section address. Run !cs -s <address> to get more information.
4052 Invalid debug information address of this critical section.
4053 Address of the debug information found in the active list.
4054 Initialization stack trace. Run dps <address> to dump the stack trace.
4056 This stop is generated if the DebugInfo field of the critical section is pointing freed memory. Usually another valid DebugInfo structure is found in the active critical section list. Without corruption the two pointers should be identical. To debug this stop use the following debugger commands: $ !cs -s -d parameter3 - dump information about this critical section based on the current contents of the debug info structure found in the active list (this structure is rarely corrupted so usually this information is trustworthy). $ !cs -s parameter1 - dump information about this critical section based on the current contents of the critical section structure (the structure is corrupted already so sometimes this information is NOT trustworthy). $ dps parameter4 - to identify the code path for initializing this critical section. Dump the critical section at address parameter1 and look for the corruption pattern. With good symbols for ntdll.dl you can use the following commands: $ dt ntdll!_RTL_CRITICAL_SECTION LOCK_ADDRESS $ dt ntdll!_RTL_CRITICAL_SECTION_DEBUG DEBUG_ADDRESS
4060 Invalid critical section owner thread.
4061 Critical section address. Run !cs -s <address> to get more information.
4062 Owning thread.
4063 Expected owning thread.
4064 Critical section debug info address.
4066 This stop is generated if the owner thread ID is invalid in the current context. For example, the critical section is being released by a thread other than the one that acquired it. To debug this stop: $ !cs -s parameter1 - dump information about this critical section. $ ln parameter1 - to show symbols near the address of the critical section. This should help identify the critical section.
4070 Invalid critical section recursion count.
4071 Critical section address. Run !cs -s <address> to get more information.
4072 Recursion count.
4073 Expected recursion count.
4074 Critical section debug info address.
4076 This stop is generated if the recursion count field of the critical section structure is invalid in the current context. To debug this stop: $ !cs -s parameter1 - dump information about this critical section. $ ln parameter1 - to show symbols near the address of the critical section. This should help identify the critical section.
4080 Deleting critical section with invalid lock count.
4081 Critical section address. Run !cs -s <address> to get more information.
4082 Lock count.
4083 Expected lock count.
4084 Owning thread.
4086 This stop is generated if a critical section is owned by a thread if it is deleted or if the critical section is uninitialized. To debug this stop: $ !cs -s parameter1 - dump information about this critical section. If the owning thread is 0 the critical section has not been initialized. $ ln parameter1 - to show symbols near the address of the critical section. This should help identify the critical section.
4090 Critical section over-released or corrupted.
4091 Critical section address. Run !cs -s <address> to get more information.
4092 Lock count.
4093 Expected lock count.
4094 Critical section debug info address.
4096 This stop is generated if a critical section is released more times than the current thread acquired it. To debug this stop: $ !cs -s parameter1 - dump information about this critical section. $ !cs -s -d parameter4 - dump information about this critical section. $ ln parameter1 - to show symbols near the address of the critical section. This should help identify the critical section.
4100 Critical section not initialized.
4101 Critical section address. Run !cs -s <address> to get more information.
4102 Critical section debug info address.
4103 Not used.
4104 Not used.
4106 This stop is generated if a critical section is used without being initialized or after it has been deleted. To debug this stop: $ ln parameter1 - to show symbols near the address of the critical section. This should help identify the critical section.
4110 Critical section is already initialized.
4111 Critical section address. Run !cs -s <address> to get more information.
4112 Critical section debug info address.
4113 First initialization stack trace. Use dps to dump it if non-NULL.
4114 Not used.
4116 This stop is generated if a critical section is reinitialized by the current thread. To debug this stop: $ !cs -s parameter1 or !cs -s -d parameter2 - dump information about this critical section. $ ln parameter1 - to show symbols near the address of the critical section. This might help identify the critical section if this is a global variable. $ dps parameter3 - to identify the code path for the first initialization of this critical section. $ kb - to display the current stack trace, that is reinitializing this critical section.
4120 Freeing virtual memory containing an active critical section.
4121 Critical section address. Run !cs -s <address> to get more information.
4122 Critical section initialization stack trace. Use dps to dump it if non-NULL.
4123 Memory block address.
4124 Memory block size.
4126 This stop is generated if the current thread is calling VirtualFree on a memory block that contains an active critical section. The application should call DeleteCriticalSection on this critical section before if frees this memory. $ kb - to display the current stack trace, that is calling VirtualFree. The probable culprit is the DLL that calls VirtualFree. $ !cs -s parameter1 - dump information about this critical section. $ dps parameter2 - to identify the code path for the initialization of this critical section.
4130 Unmapping memory region containing an active critical section.
4131 Critical section address. Run !cs -s <address> to get more information.
4132 Critical section initialization stack trace. Use dps to dump it if non-NULL.
4133 Memory block address.
4134 Memory block size.
4136 This stop is generated if the current thread is calling UnmapViewOfFile on a memory block that contains an active critical section. The application should call DeleteCriticalSection on this critical section before if unmaps this memory. $ kb - to display the current stack trace, that is calling UnmapViewOfFile . The probable culprit is the DLL that calls UnmapViewOfFile. $ !cs -s parameter1 - dump information about this critical section. $ dps parameter2 - to identify the code path for the initialization of this critical section.
4140 Current thread does not own any critical sections.
4141 Critical section address. Run !cs -s <address> to get more information.
4142 Number of critical sections owned by current thread.
4143 Not used
4144 Not used
4146 This stop is generated if the current thread is calling LeaveCriticalSection but, according to the internal verifier bookkeeping, it doesn't own any critical section. If parameter2 is zero, probably this is a bug in the current thread. It either tries to leave a critical section that it didn't enter, or maybe it is calling LeaveCriticalSection more times than it called EnterCriticalSection for the same critical section. If parameter2 is not zero (it is a negative integer number) the internal verifier data structures are probably corrupted.
4150 Using critical section that is private to another DLL.
4151 Critical section address. Run !cs -s <address> to get more information.
4152 Not used.
4153 Not used
4154 Not used
4156 This stop is generated if the current thread tries to use a private lock that lives inside another DLL. For example a.dll tries to enter a critical section defined inside ntdll.dll. Private locks cannot be used across DLLs.
4500 The SRW Lock is not initialized.
4501 SRW Lock
4502 Not used
4503 Not used
4504 Not used
4506 This stop is generated if a thread is trying to use the SRW lock (Param1) that is not initialized. $ kb - to get the current stack trace. This is where the SRW lock is being used. The SRW lock should be initialized using InitializeSRWLock before it can be used.
4510 The SRW Lock is already initialized.
4511 SRW Lock
4512 ThreadId of the thread that initialized the SRW lock.
4513 Address of the initialization stack trace. Use dps <address> to see where the SRW lock was initialized.
4514 Not used
4516 This stop is generated if the SRW lock (Param1) is being re-initialized. If the SRW lock is being actively used by other threads, re-initializing the lock will result in unpredictable behavior by the application including hangs and crashes. The initialization stack trace may show an acquire if the SRW lock was statically initialized. $ kb - to get the current stack trace. This is where the SRW lock is being re-initialized. $ dps Param3 - to get the SRW lock initialization stack trace. This stack trace may show an acquire if the lock was statically initialized.
4520 Mismatched Acquire-Release on the SRW lock.
4521 SRW Lock
4522 ThreadId of the thread that acquired the SRW lock.
4523 Address of the acquire stack trace. Use dps <address> to see where the SRW lock was acquired.
4524 Not used
4526 This stop is generated if the SRW lock (Param1) is being released with a wrong release API. If the SRW lock was acquired for shared access and is being released using the exclusive release API or the SRW lock was acquired for exclusive access and is being release using the shared release API. This can result in unpredictable behavior by the application including hangs and crashes. $ kb - to get the current stack trace. This is where the SRW lock is being released using the wrong API. $ dps Param3 - to get the SRW lock acquire stack trace.
4530 The SRW lock is being acquired recursively by the same thread.
4531 SRW Lock
4532 Address of the first acquire stack trace. Use dps <address> to see where the SRW lock was acquired.
4533 Not used
4534 Not used
4536 This stop is generated if the SRW lock (Param1) is being acquired recursively by the same thread. This will result in a deadlock and the thread would block indefinitely. Recursive acquisition of an SRW lock in exclusive mode will cause a deadlock. Recursive acquisition of an SRW lock in shared mode will cause a deadlock when there is a thread waiting for exclusive access. Consider the example below: - Thread A acquires the SRW lock in shared mode - Thread B tries to acquire the SRW lock in exclusive mode and waits - Thread A tries to acquire the SRW lock in shared mode recursively. This will be successful as long as there is no exclusive waiter (in this case B). Since SRW locks do not have writer starvation, thread A waits behind thread B. Now, Thread B is waiting for Thread A which is inturn waiting for Thread B causing a circular wait and hence a deadlock. $ kb - to get the current stack trace. This is where the SRW lock is being acquired recursively. $ dps Param2 - to get the stack trace for the first acquire.
4540 The thread that is exiting or being terminated owns an SRW lock.
4541 SRW Lock
4542 ThreadId of the thread that is exiting or being terminated.
4543 Address of the acquire stack trace. Use dps <address> to see where the SRW lock was acquired.
4544 Not used
4546 This stop is generated if the thread (Param2) that owns the SRW lock (Param1) is exiting or being terminated. This will result in an orphaned SRW lock and the threads trying to acquire this lock would block indefinitely. $ kb - to get the current stack trace. This is where the thread is exiting or is being terminated. $ dps Param3 - to get the SRW lock acquire stack trace.
4550 The SRW lock being released was not acquired by this thread.
4551 SRW Lock
4552 Current ThreadId.
4553 ThreadId of the thread that acquired the SRW lock.
4554 Address of the acquire stack trace. Use dps <address> to see where the SRW lock was acquired.
4556 This stop is generated if the SRW lock (Param1) is being released by the thread (Param2) that didn't acquire the lock. This represents bad programming practice that is hard to get right and can lead to unpredictable behavior by the application. $ kb - to get the current stack trace. This is where the thread is releasing the SRW lock that it didn't acquire. $ dps Param4 - to get the SRW lock acquire stack trace.
4560 The memory being freed contains an active SRW lock.
4561 SRW Lock
4562 Address of the memory being freed.
4563 ThreadId of the thread that acquired the SRW lock.
4564 Address of the acquire stack trace. Use dps <address> to see where the SRW lock was acquired.
4566 This stop is generated if the memory address (Param1) being freed contains an active SRW lock that is still in use. This can result in unpredictable behavior by the application including crashes and hangs. $ kb - to get the current stack trace. This is where the memory is being freed that contains an active SRW lock. $ dps Param4 - to get the SRW lock acquire stack trace.
4570 The DLL being unloaded contains an active SRW lock.
4571 SRW Lock
4572 Address of the name of the DLL being unloaded. Use du <address> to see the name.
4573 ThreadId of the thread that acquired the SRW lock.
4574 Address of the acquire stack trace. Use dps <address> to see where the SRW lock was acquired.
4576 This stop is generated if the DLL being unloaded (Param2) contains an active SRW lock (Param1) that is still in use. This can result in unpredictable behavior by the application including crashes and hangs. $ kb - to get the current stack trace. This is where the DLL is being unloaded that contains an active SRW lock. $ du Param2 - to find the name of the DLL that is being unloaded. $ dps Param4 - to get the SRW lock acquire stack trace.
5000 Invalid handle exception for current stack trace.
5001 Exception code.
5002 Exception record. Use .exr to display it.
5003 Context record. Use .cxr to display it.
5004 Not used.
5006 This stop is generated if the function on the top of the stack passed an invalid handle to system routines. Usually a simple kb command will reveal what is the value of the handle passed (must be one of the parameters - usually the first one). If the value is null then this is clearly wrong. If the value looks ok you need to use !htrace debugger extension to get a history of operations pertaining to this handle value. In most cases it must be that the handle value is used after being closed.
5010 Invalid TLS index used for current stack trace.
5011 Invalid TLS index.
5012 Expected lower part of the index.
5013 Not used.
5014 Not used.
5016 This stop is generated if the function on the top of the stack passed an invalid TLS index to TLS system routines. Usually a simple kb command will reveal what is wrong. The typical bug here is to assume a certain value for a TLS index instead of calling TlsAlloc. This can happen either by thinking that you always get value N therefore there is no need to call TlsAlloc or more frequently due to an uninitialized variable.
5020 Invalid parameters for WaitForMultipleObjects call.
5021 Address of object handles vector.
5022 Number of handles.
5023 Not used.
5024 Not used.
5026 This stop is generated if the function on the top of the stack called WaitForMultipleObjects with NULL as the address of the array of handles to wait for or with zero as the number of handles. A simple kb command will reveal the function calling this API incorrectly.
5030 NULL handle passed as parameter. A valid handle must be used.
5031 Not used.
5032 Not used.
5033 Not used.
5034 Not used.
5036 This stop is generated if the function on the top of the stack passed a NULL handle to system routines.
5040 Waiting on a thread handle in DllMain.
5041 Thread handle.
5042 Not used.
5043 Not used.
5044 Not used.
5046 This stop is generated if the current thread is currently running code inside the DllMain function of one of the DLLs loaded in the current process and it calls WaitForSingleObject or WaitForMultipleObjects to wait on a thread handle in the same process. This would most likely lead to a deadlock because the thread handle will not get signaled unless that second thread is exiting. When the second thread will call ExitThread it will try to acquire the DLL loader lock then call DllMain (DLL_THREAD_DETACH) for all DLLs in the current process. But the loader lock is owned by the first thread (the one that is waiting on the thread handle) so the two threads will deadlock.
5050 Incorrect object type for handle.
5051 Handle value.
5052 Object type name. Use du to display it
5053 Expected object type name. Use du to display it
5054 Not used.
5056 This stop is generated if the current thread is calling an API with a handle to an object with an incorrect object type. E.g. calling SetEvent with a semaphore handle as parameter will generate this stop. To debug this stop: $ kb - to display the current stack trace. The culprit is probably the DLL that is calling into verifier.dll; $ du parameter2 - to display the actual type of the handle. The handle value is parameter1. In the example above, this will display: Semaphore. $ du parameter3 - to display the object type expected by the API. In the example above, this name will be: Event. $ !htrace parameter1 might be helpful because it will display the stack trace for the recent open/close operations on this handle.
6000 Unloading DLL that allocated TLS index that was not freed.
6001 TLS index
6002 Address of the code that allocated this TLS index.
6003 DLL name address. Use du to dump it.
6004 DLL base address.
6006 This stop is generated if a DLL that allocated a TLS index is being unloaded before freeing that TLS index. To debug this stop: $ du parameter3 - display the name of the culprit DLL; $ .reload xxx.dll=parameter4 - reload symbols for the culprit DLL (if needed). xxx.dll is the name of the DLL displayed in the above step; $ u parameter2 - disassemble the code that allocated the TLS. This should point to the function that allocated the TLS but forgot to free it before the DLL was unloaded.
6010 Corrupted verifier TLS structure.
6011 TEB address.
6012 Expected TEB address.
6013 Thread ID.
6014 Expected thread ID.
6016 This stop is generated if the internal verifier structures used to store the state of TLS slots for thread are corrupted. Very likely this is due to some random corruption in the process.
6020 Using an invalid TLS index.
6021 TLS index
6022 Not Used.
6023 Not Used.
6024 Not Used.
6026 This stop is generated if an invalid TLS index is used. In most cases, it's because code is still using this index when TlsFree is called. Here is an example for the threadpool thread. T1: Dll loads and TlsAlloc T1: Queue callback T1: Skipped waited/cancelled callback T1: TlsFree T2: Callback runs and calls TlsSetValue T1: Dll unloads
7000 Freeing virtual memory block with invalid size or start address.
7001 Allocation base address.
7002 Memory region size.
7003 Not used.
7004 Not used.
7006 This stop is generated if the app verifier detects a VirtualFree or a DLL unload with an invalid start address or size of the memory allocation. In the case of DLL unload this probably means a memory corruption inside the loaded DLL list. To debug this stop look at the current stack trace and the memory address and size that is about to be freed and try to determine why they are invalid.
7010 Incorrect virtual alloc call.
7011 Pointer to allocation base address.
7012 Pointer to memory region size.
7013 Not used
7014 Not used
7016 This stop is generated if the app verifier detects a VirtualAlloc call with an invalid start address or size of the memory allocation. To debug this stop look at the current stack trace (kb) and the memory address and size that is about to be allocated and try to determine why they are invalid.
7020 Incorrect map view call.
7021 Pointer to mapping base address.
7022 Pointer to view size.
7023 Not used.
7024 Not used.
7026 This stop is generated if the app verifier detects a MapViewOfFile call with an invalid base address or size of the mapping. To debug this stop look at the current stack trace (kb) and the memory address and size that is about to be mapped and try to determine why they are invalid.
7030 Probing invalid address.
7031 Start address.
7032 Memory block size.
7033 Invalid address.
7034 Not used.
7036 This stop is generated if the app verifier detects an IsBadXXXPtr call with an invalid address (e.g. a kernel-mode address, instead of a normal user-mode address) for the memory buffer to be probed. To debug this stop look at the current stack trace (kb) and try to determine why the caller of the IsBadXXXPtr function ended up with an invalid address. Many times, the address is plain bogus, e.g. an uninitialized pointer. MSDN library lists a few reasons why applications should not use the IsBadXXXPtr APIs: In a preemptive multitasking environment, it is possible for some other thread to change the process's access to the memory being tested. Dereferencing potentially invalid pointers can disable stack expansion in other threads. A thread exhausting its stack, when stack expansion has been disabled, results in the immediate termination of the parent process, with no pop-up error window or diagnostic information. Threads in a process are expected to cooperate in such a way that one will not free memory that the other needs. Use of this function does not negate the need to do this. If this is not done, the application may fail in an unpredictable manner. Because of all these reasons, we recommend to never use these APIs.
7040 Probing free memory.
7041 Start address.
7042 Memory block size.
7043 Address of free memory page.
7044 Not used.
7046 This stop is generated if the app verifier detects an IsBadXXXPtr call for a memory allocation that is free. This is very bad because it is possible that, in some other cases, this memory was already reused for some other allocation. Since the current code path (kb) doesn't own that memory, it could end up corrupting someone else's memory, with disastrous effects. To debug this stop look at the current stack trace (kb) and try to determine why the caller of the IsBadXXXPtr function ended up probing free memory. The address could be plain bogus (e.g. uninitialized pointer) or maybe already freed memory. If the memory was already freed by one of the VirtualFree or UnmapViewOfFile APIs, `!avrf -vs -a parameter3' will search for a log of stack traces of the code paths that allocated/freed that address and display these stack traces if they are available. This might show the stack trace that freed up this memory. More often, the memory is an already freed heap allocation. To check for that possibility, `!avrf -hp -a parameter3' will search for a log of stack traces of the code paths that allocated/freed that address from/to the heap and display these stack traces if they are available. MSDN library lists a few reasons why applications should not use the IsBadXXXPtr APIs: In a preemptive multitasking environment, it is possible for some other thread to change the process's access to the memory being tested. Dereferencing potentially invalid pointers can disable stack expansion in other threads. A thread exhausting its stack, when stack expansion has been disabled, results in the immediate termination of the parent process, with no pop-up error window or diagnostic information. Threads in a process are expected to cooperate in such a way that one will not free memory that the other needs. Use of this function does not negate the need to do this. If this is not done, the application may fail in an unpredictable manner. Because of all these reasons, we recommend to never use these APIs.
7050 Probing a guard page.
7051 Start address.
7052 Memory block size.
7053 Address of guard page.
7054 Not used.
7056 This stop is generated if the app verifier detects an IsBadXXXPtr call for a memory allocation that contains at least one GUARD_PAGE. This is very bad because it is very possible that this GUARD_PAGE is the end of the current stack of a thread. As documented in the MSDN library: Dereferencing potentially invalid pointers can disable stack expansion in other threads. A thread exhausting its stack, when stack expansion has been disabled, results in the immediate termination of the parent process, with no pop-up error window or diagnostic information. To debug this stop look at the current stack trace (kb) and try to determine why the caller of the IsBadXXXPtr function ended up probing a GUARD_PAGE. MSDN library lists a few reasons why applications should not use the IsBadXXXPtr APIs: In a preemptive multitasking environment, it is possible for some other thread to change the process's access to the memory being tested. Dereferencing potentially invalid pointers can disable stack expansion in other threads. A thread exhausting its stack, when stack expansion has been disabled, results in the immediate termination of the parent process, with no pop-up error window or diagnostic information. Threads in a process are expected to cooperate in such a way that one will not free memory that the other needs. Use of this function does not negate the need to do this. If this is not done, the application may fail in an unpredictable manner. Because of all these reasons, we recommend to never use these APIs.
7060 Probing NULL address.
7061 Not used.
7062 Not used.
7063 Not used.
7064 Not used.
7066 This stop is generated if the app verifier detects an IsBadXXXPtr call with a NULL address. To debug this stop look at the current stack trace (kb) and try to determine why the caller of the IsBadXXXPtr function ended up with the NULL address. This is typically the sign of someone not checking the return value of one of the memory allocation functions. For example the code below is incorrect: int main (void) { PVOID p; p = malloc (1024); Use (p); return 0; } void Use (PVOID p) { if (IsBadReadPtr (p)) { return; } // // p is safe to be used here. // } This code should be re-written as this: int main (void) { PVOID p; p = malloc (1024); if (NULL == p)) { return -1; } Use (p); return 0; } void Use (PVOID p) { // // p is safe to be used here. // } MSDN library lists a few reasons why applications should not use the IsBadXXXPtr APIs: In a preemptive multitasking environment, it is possible for some other thread to change the process's access to the memory being tested. Dereferencing potentially invalid pointers can disable stack expansion in other threads. A thread exhausting its stack, when stack expansion has been disabled, results in the immediate termination of the parent process, with no pop-up error window or diagnostic information. Threads in a process are expected to cooperate in such a way that one will not free memory that the other needs. Use of this function does not negate the need to do this. If this is not done, the application may fail in an unpredictable manner. Because of all these reasons, we recommend to never use these APIs.
7070 Probing memory block with invalid start address or size.
7071 Start address.
7072 Memory block size.
7073 Not used.
7074 Not used.
7076 This stop is generated if the app verifier detects an IsBadXXXPtr call with an invalid start address (e.g. a kernel-mode address, instead of a normal user-mode address) or invalid size for the memory buffer to be probed. To debug this stop look at the current stack trace (kb) and try to determine why the caller of the IsBadXXXPtr function ended up with an invalid address or size. Many times, the address or size are plain bogus, e.g. an uninitialized variables. MSDN library lists a few reasons why applications should not use the IsBadXXXPtr APIs: In a preemptive multitasking environment, it is possible for some other thread to change the process's access to the memory being tested. Dereferencing potentially invalid pointers can disable stack expansion in other threads. A thread exhausting its stack, when stack expansion has been disabled, results in the immediate termination of the parent process, with no pop-up error window or diagnostic information. Threads in a process are expected to cooperate in such a way that one will not free memory that the other needs. Use of this function does not negate the need to do this. If this is not done, the application may fail in an unpredictable manner. Because of all these reasons, we recommend to never use these APIs.
7080 Unloading DLL with invalid size or start address.
7081 DLL memory base address.
7082 DLL memory range size.
7083 DLL name address. Use du to dump it.
7084 Not used.
7086 This stop is generated if the app verifier detects a DLL unload with an invalid start address or size of the DLL memory range. This probably means a memory corruption inside the internal ntdll.dll loaded DLL list.
7090 Freeing memory block inside current thread's stack address range.
7091 Allocation base address.
7092 Memory region size.
7093 Stack low limit address.
7094 Stack high limit address.
7096 This stop is generated if the app verifier detects a VirtualFree for a block of memory that is actually part of the current thread's stack (!). To debug this stop look at the current stack trace (kb) and try to understand why the function that called VirtualFree thought that the memory block was dynamically allocated or mapped but that was actually memory allocated from the stack.
7100 Incorrect FreeType parameter for VirtualFree operation.
7101 Incorrect value used by the application.
7102 Expected correct value 1.
7103 Expected correct value 2.
7104 Not used.
7106 This stop is generated if the app verifier detects a VirtualFree with an incorrect value for the FreeType parameter. The only two acceptable values for this parameter are MEM_DECOMMIT and MEM_RELEASE. If VirtualFree is called with any other value except these two, VirtualFree will fail to free the memory. To debug this stop look at the current stack trace (kb): the caller of VirtualFree is probably the culprit.
7110 Trying to free virtual memory block that is already free.
7111 Memory block address.
7112 Not used.
7113 Not used.
7114 Not used.
7116 This stop is generated if the app verifier detects a VirtualFree for an address that is already free. To debug this stop look at the current stack trace (kb) and try to determine why the memory is already free but the application is trying to free it again. `!avrf -vs -a parameter1' will search for a log of stack traces of the code paths that allocated/freed that address and display these stack traces if they are available. This might show the stack trace that freed up this memory.
7120 Incorrect Size parameter for VirtualFree (MEM_RELEASE) operation.
7121 Incorrect size used by the application.
7122 Expected correct size (0).
7123 Not used.
7124 Not used.
7126 This stop is generated if the app verifier detects a VirtualFree (MEM_RELEASE) with a non-zero value for the dwSize parameter. When using MEM_RELEASE , the only acceptable value for this parameter is 0. If VirtualFree is called with any other value except 0, VirtualFree will fail to free the memory. To debug this stop look at the current stack trace (kb): the caller of VirtualFree is probably the culprit.
7130 Unexpected exception raised in DLL entry point routine.
7131 DLL name (use du to dump it).
7132 Exception record. Use .exr to display it.
7133 Context record. Use .cxr to display it.
7134 Verifier dll descriptor
7136 This stop is generated if a DLL's entry point (DllMain) function is raising an exception. One example why this is bad is: if DllMain(DLL_PROCESS_ATTACH) is raising an exception, the Windows DLL loader will: - Catch and hide the exception; - Unload the DLL without calling its DllMain(DLL_PROCESS_DETACH). So in many cases the DLL allocated some resources already, then it raised the exception, and it will not have a chance to release these resources on DllMain (DLL_PROCESS_DETACH). To debug this stop: $ du parameter1 - to display the DLL name; $ .exr parameter2 - to display the exception information; $ .cxr parameter3 followed by kb - to display the exception context information and the stack trace for the time when the exception was raised; $ parameter4 is the address of an internal verifier structure and doesn't have any significance for most of the verifier users.
7140 Unexpected exception raised in thread function.
7141 Exception code.
7142 Exception record. Use .exr to display it.
7143 Context record. Use .cxr to display it.
7144 Not used.
7146 This stop is generated if a thread function is raising an exception. This is bad because the whole process will be killed. To debug this stop: $ parameter1 might be significant for the type of exception. E.g. an exception code C0000005 means Access Violation; $ .exr parameter2 - to display the exception information; $ .cxr parameter3 followed by kb - to display the exception context information;
7150 Unexpected exception raised while probing memory.
7151 Exception code.
7152 Exception record. Use .exr to display it.
7153 Context record. Use .cxr to display it.
7154 Not used
7156 This stop is generated if we get an exception during an IsBadXXXPtr call. This means that the memory buffer we are probing doesn't actually have the protection assumed by the caller, or that the memory was freed already, etc. See the discussion above about other stop code (PROBE_INVALID_ADDRESS, PROBE_FREE_MEM, PROBE_GUARD_PAGE, PROBE_NULL, PROBE_INVALID_START_OR_SIZE) for more examples of why using the IsBadXXXPtr APIs is not recommended. To debug this stop: $ parameter1 will typically be C0000005 and that means Access Violation; $ .exr parameter2 - to display the exception information; $ .cxr parameter3 followed by kb - to display the exception context information and stack trace at the time when the exception was raised;
7160 Trying to reset NULL address.
7161 Not used.
7162 Not used.
7163 Not used.
7164 Not used.
7166 This stop is generated if the app verifier detects a VirtualFree (MEM_RESET) call with a NULL first parameter. MEM_RESET should be used only for already allocated memory, so NULL is not a valid first parameter in this case.
7170 Freeing heap memory block inside current thread's stack address range.
7171 Allocation base address.
7172 Memory region size.
7173 Stack low limit address.
7174 Stack high limit address.
7176 This stop is generated if the app verifier detects a HeapFree, for a block of memory that is actually part of the current thread's stack (!). To debug this stop look at the current stack trace (kb) and try to understand why the function that called HeapFree thought that the memory block was dynamically allocated or mapped but that was actually memory allocated from the stack.
7180 Unmapping memory region inside current thread's stack address range.
7181 Allocation base address.
7182 Memory region size.
7183 Stack low limit address.
7184 Stack high limit address.
7186 This stop is generated if the app verifier detects an UnmapViewOfFile, for a block of memory that is actually part of the current thread's stack (!). To debug this stop look at the current stack trace (kb) and try to understand why the function that called UnmapViewOfFile thought that the memory block was dynamically allocated or mapped but that was actually memory allocated from the stack.
7190 Incorrect RTL_RESOURCE address.
7191 Address.
7192 Not used.
7193 Not used.
7194 Not used.
7196 This stop is generated if the application is trying to use NULL or some other incorrect address (e.g. a kernel-mode address) as the address of a valid object. RtlInitializeResource (NULL) is an incorrect API call that will trigger this kind of verifier stop. param1 is the incorrect address used and the culprit is on the stack trace (display it with kb).
7200 Invalid critical section address.
7201 Address.
7202 Not used.
7203 Not used.
7204 Not used.
7206 This stop is generated if the application is trying to use NULL or some other incorrect address (e.g. a kernel-mode address) as the address of a valid object. EnterCriticalSection(NULL) is an incorrect API call that will trigger this kind of verifier stop. param1 is the incorrect address used and the culprit is on the stack trace (display it with kb).
7210 Attempt to execute code in non-executable memory.
7211 Address being accessed.
7212 Code performing invalid access.
7213 Exception record. Use .exr to display it.
7214 Context record. Use .cxr to display it.
7216 This stop is generated if the application is trying to run code from an address that is non-executable or free. To debug this stop: $ u parameter2 - to unassemble the culprit code $ .exr parameter3 - to display the exception information; $ .cxr parameter4 followed by kb - to display the exception context information and the stack trace for the time when the exception was raised.
7220 Unexpected exception raised while initializing output buffer.
7221 Buffer start address.
7222 Buffer size.
7223 Exception record. Use .exr to display it.
7224 Context record. Use .cxr to display it.
7226 This stop is generated if we get an exception while initializing a buffer specified as output parameter for a Win32 or CRT API. This typically means that the specified output buffer size is incorrect. To debug this stop: $ .exr parameter3 - to display the exception information; $ .cxr parameter4 followed by kb - to display the exception context information and stack trace at the time when the exception was raised.
7230 Unexpected exception when trying to find heap block size.
7231 Address of the heap block being freed.
7232 Heap handle.
7233 Exception record. Use .exr to display it.
7234 Context record. Use .cxr to display it.
7236 This stop is generated if we get an exception while calling HeapSize for a heap block that is being freed. This typically means that the specified heap block address is incorrect or the heap is corrupted. To debug this stop: $ .exr parameter3 - to display the exception record; $ .cxr parameter4 followed by kb - to display the exception context information and stack trace at the time when the exception was raised.
7240 Freeing memory block with invalid start address.
7241 Address of memory block being freed.
7242 Expected correct memory block address.
7243 Not used.
7244 Not used.
7246 This stop is generated if the program calls VirtualFree (MEM_RELEASE) with an lpAddress parameter that is not the base address returned by the VirtualAlloc or VirtualAllocEx function when the region of pages was reserved; To debug this stop: $ kb - to display the current stack trace, that is calling VirtualFree. The probable culprit is the DLL that calls VirtualFree.
7250 Unmapping memory block with invalid start address.
7251 Address of memory block being unmapped.
7252 Expected correct memory block address.
7253 Not used.
7254 Not used.
7256 This stop is generated if the program calls UnmapViewOfFile with an lpBaseAddress parameter that is not identical to the value returned by a previous call to the MapViewOfFile or MapViewOfFileEx function. To debug this stop: $ kb - to display the current stack trace, that is calling UnmapViewOfFile. The probable culprit is the DLL that calls UnmapViewOfFile.
7260 unexpected exception raised in threadpool callback function.
7261 Exception code
7262 Exception record. Use .exr to display it
7263 Context record. Use .cxr to display it
7264 Not used
7266 This stop is generated if a callback function in the threadpool thread is raising an exception. To debug this stop: $ parameter1 might be significant for the type of exception. E.g. an exception code C0000005 means Access Violation. $ .exr parameter2 - to display the exception information. $ .cxr parameter3 followed by kb - to display the exception context information.
7270 code in non-executable memory
7271 Address being accessed
7272 Code performing invalid access
7273 Exception record. Use .exr to display it.
7274 Context record. Use .cxr to display it.
7276 This stop is generated if the application is trying to run code from an address that is non-executable or free. To debug this stop: $ u parameter2 - to unassemble the culprit code $ .exr parameter3 - to display the exception information $ .cxr parameter4 followed by kb - to display the exception context information and the stack trace for the time when the exception was raised.
7280 Creating executable heap.
7281 Not used.
7282 Not used.
7283 Not used.
7284 Not used.
7286 This stop is generated if the application is creating an executable heap. This can be a security risk.
7290 Allocating executable memory.
7291 Page protection specified by caller.
7292 Not used.
7293 Not used.
7294 Not used.
7296 This stop is generated if the application is allocating executable memory. This can be a security risk.
8000 Attempt to execute code in non-executable memory (first chance).
8001 Address being accessed.
8002 Code performing invalid access.
8003 Exception record. Use .exr to display it.
8004 Context record. Use .cxr to display it.
8006 This stop is generated if the application is trying to run code from an address that is non-executable or free. To debug this stop: $ u parameter2 - to unassemble the culprit code $ .exr parameter3 - to display the exception information; $ .cxr parameter4 followed by kb - to display the exception context information and the stack trace for the time when the exception was raised.
9000 The priority of this threadpool thread has been changed.
9001 Callback function where the priority has been changed.
9002 Context.
9003 Threadpool Object allocation stack trace, use dps to dump it.
9004 Current Priority.
9005 threadpool thread (%x) having executed Callback (%p) has an altered thread priority (%i -> %i)
9006 This stop is generated if the thread priority is changed when it's returned to threadpool.
9010 The affinity of this threadpool thread has been changed.
9011 Callback function where the affinity has been changed.
9012 Context.
9013 Threadpool Object allocation stack trace, use dps to dump it.
9014 Current affinity.
9015 threadpool thread (%x) having executed Callback (%p) has an altered thread affinity mask (%p -> %p)
9016 This stop is generated if the thread affinity is changed when it's returned to threadpool.
9020 Unprocessed msg in the msg pool of current thread.
9021 Callback function that posted the message.
9022 Context.
9023 Threadpool Object allocation stack trace, use dps to dump it.
9024 Threadpool thread id. Please use !avrf -tp <threadid> to see the messages posted to this thread.
9025 threadpool thread (%x) having executed Callback (%p) has outstanding window message (%x: %x)
9026 This stop is generated if any message left as unprocessed when this threadpool thread is returned to the pool. It's dangerous since it will be processed in a totally different context. Please use Please use !avrf -tp <Param4> to see the messages posted to this thread.
9030 Unclosed window belonged to the current thread.
9031 Callback function.
9032 Context.
9033 Threadpool Object allocation stack trace, use dps to dump it.
9034 Threadpool thread id.
9035 threadpool thread (%x) having executed Callback (%p) has valid hwnd (%x: %s) which could receive messages
9036 This stop is generated if any window is kept alive when this threadpool thread is returned to the pool.
9040 ExitThread() called on a threadpool thread.
9041 Callback function.
9042 Context.
9043 Threadpool Object allocation stack trace, use dps to dump it.
9044 Not Used.
9046 This stop is generated if ExitThread is called on a threadpool thread.It's forbidden since it will make system unstable. It will cause resource leak, hang or AV.
9050 Thread is in impersonation state when it's returned to a threadpool thread.
9051 Callback function where the thread was impersonated.
9052 Context.
9053 Threadpool Object allocation stack trace, use dps to dump it.
9054 Not Used.
9056 This stop is generated if call back function change the thread token to impersonate another user and forgot to reset it before returning it back to the threadpool.
9060 A function which requires persistent thread is called within the callback.
9061 Callback function.
9062 Context.
9063 Threadpool Object allocation stack trace, use dps to dump it.
9064 Not Used.
9066 Some Microsoft Windows APIs need to be called inside a dedicated or persistent thread. In the threadpool you should generally avoid using thread local storage and queuing asynchronous calls that require a persistent thread, such as the RegNotifyChangeKeyValue function. However, such functions can be queued to a persistent worker thread using QueueUserWorkItem with the WT_EXECUTEINPERSISTENTTHREAD option. A kb in debugger will reveal the caller.
9070 Thread is in dirty transaction state.
9071 Callback function where the transaction context was changed.
9072 Context.
9073 Threadpool Object allocation stack trace, use dps to dump it.
9074 Transaction Handle.
9076 This stop is generated if call back function forgot to close or reset the current transaction handle.
9080 This threadpool state has unbalanced CoInit and CoUnInit calls.
9081 Callback function that left the thread in a dirty com state.
9082 Context.
9083 Threadpool Object allocation stack trace, use dps to dump it.
9084 Balanced Call counts.
9086 This stop is generated if call back function calls CoInit and CoUnInit unbalanced.
9090 The parameters for the timer object are inconsistent. Period should be 0 when WT_EXECUTEONLYONCE is specified when creating the timer
9091 Period specified.
9092 Flags specified.
9093 Not Used.
9094 Not Used.
9096 This stop is generated if the period to signal the timer is not zero when the timer is set to signal only once with the WT_EXECUTEONLYONCE flag
9100 The loader lock has been held by the threadpool thread within the callback.
9101 Callback function.
9102 Context.
9103 Threadpool Object allocation stack trace, use dps to dump it.
9104 Not Used.
9106 This stop is generated if the loader lock is held within the callback and is not released when the thread is returned to the threadpool.
9110 The preferred language is set by the threadpool thread within the callback.
9111 Callback function.
9112 Context.
9113 Threadpool Object allocation stack trace, use dps to dump it.
9114 Not Used.
9116 This stop is generated if the preferred language is set within the callback and is not cleared when the thread is returned to the threadpool.
9120 The background priority is set by the threadpool thread within the callback.
9121 Callback function.
9122 Context.
9123 Threadpool Object allocation stack trace, use dps to dump it.
9124 Not Used.
9126 This stop is generated if the background priority is set within the callback and is not disabled when the thread is returned to the threadpool.
9130 TerminateThread() called on a threadpool thread.
9131 Not Used.
9132 Not Used.
9133 Not Used.
9134 Not Used.
9136 This stop is generated if TerminateThread is called on a threadpool thread. It's forbidden since it will make system unstable. It will cause resource leak, hang or AV.
9500 The stack was unwinded when asynchronous I/O operation is pending.
9501 Address of stack variable used in the I/O.
9502 Current stack pointer.
9503 Original thread that issued the I/O.
9504 Stack Trace when the I/O was issued.
9506 This stop is generated if the application issued an I/O operation that uses a stack variable and has not waited for the I/O to complete, thus leading to stack corruption. To debug this stop: $ dps parameter4 to display the stack trace when the I/O was issued. Parameter1 indicates the stack based address and parameter3 the thread that issued the I/O.
9510 The stack was corrupted when asynchronous I/O operation is pending.
9511 Address of the stack variable used in the I/O.
9512 Current stack pointer.
9513 Original thread that issued the I/O.
9514 Stack Trace when the I/O was issued.
9516 This stop is generated if the application issued an I/O operation that uses a stack variable and has not waited for the I/O to complete, thus leading to stack corruption. To debug this stop: $ dps parameter4 to display the stack trace when the I/O was issued. Parameter1 indicates the stack based address and parameter3 the thread that issued the I/O.
9520 Using a freed address in a pending I/O operation.
9521 Address used in the I/O.
9522 Address being freed.
9523 Original thread that issued the I/O.
9524 Stack Trace when the I/O was issued.
9526 This stop is generated if the application issued an I/O operation and freed the memory used in the I/O before the I/O completed thus leading to memory corruption etc. To debug this stop: $ dps parameter4 to display the stack trace when the I/O was issued. Parameter1 indicates the address used in the I/O. Parameter2 indicates the address being freed and parameter3 the thread that issued the I/O.
9530 An I/O status block (OVERLAPPED) is reused while associated I/O request is still pending.
9531 Address of the I/O status block (OVERLAPPED).
9532 Original thread that issued the I/O.
9533 Stack Trace when the I/O was issued.
9534 Not Used.
9536 This stop is generated if the application reused an I/O status block (OVERLAPPED) while an I/O request using that I/O status block (OVERLAPPED) is still pending. To debug this stop: $ dps parameter3 to display the stack trace when the original I/O was issued. Parameter1 indicates the address used in the I/O and parameter2 the thread that issued the I/O.
9540 Using an unsupported flag, FILE_ATTRIBUTE_NOT_CONTENT_INDEXED on CreateFile
9541 Return Address.
9542 Not used.
9543 Not used.
9544 Not used.
9545 CreateFile while writing %hs%ws with flags %08x %08x %08x
9546 Old version of the MSDN erroneously documented CreateFile as supporting FILE_ATTRIBUTE_NOT_CONTENT_INDEXED. If this flag is intended it should be set using other API functions such as SetFileAttributes. $ ln Parameter1 to find the caller of CreateFile.
10500 A heap allocation was leaked.
10501 Address of the leaked allocation. Run !heap -p -a <address> to get additional information about the allocation.
10502 Address to the allocation stack trace. Run dps <address> to view the allocation stack.
10503 Address of the owner dll name. Run du <address> to read the dll name.
10504 Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.
10506 This stop is generated if the owner dll of the allocation was dynamically unloaded while owning resources.
10510 A HANDLE was leaked.
10511 Value of the leaked handle. Run !htrace <handle> to get additional information about the handle if handle tracing is enabled.
10512 Address to the allocation stack trace. Run dps <address> to view the allocation stack.
10513 Address of the owner dll name. Run du <address> to read the dll name.
10514 Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.
10516 This stop is generated if the owner dll of the handle was dynamically unloaded while owning resources. To debug this stop: Run !htrace parameter1 to get additional information about the handle.
10520 An HKEY was leaked.
10521 Value of the leaked HKEY.
10522 Address to the allocation stack trace. Run dps <address> to view the allocation stack.
10523 Address of the owner dll name. Run du <address> to read the dll name.
10524 Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.
10526 This stop is generated if the owner dll of the registry key was dynamically unloaded while owning resources.
10530 A virtual reservation was leaked.
10531 Leaked reservation address.
10532 Address to the allocation stack trace. Run dps <address> to view the allocation stack.
10533 Address of the owner dll name. Run du <address> to read the dll name.
10534 Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.
10536 This stop is generated if the owner dll of the virtual reservation was dynamically unloaded while owning resources.
10540 A BSTR was leaked.
10541 Address of the leaked BSTR. Run !heap -p -a <address> to get additional information about the allocation.
10542 Address to the allocation stack trace. Run dps <address> to view the allocation stack.
10543 Address of the owner dll name. Run du <address> to read the dll name.
10544 Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.
10546 This stop is generated if the owner dll of the SysString was dynamically unloaded while owning resources.
10550 A power notification was not unregistered.
10551 Address of the power notification registration.
10552 Address to the registration stack trace. Run dps <address> to view the allocation stack.
10553 Address of the owner dll name. Run du <address> to read the dll name.
10554 Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.
10556 This stop is generated if the dll registered for power notification and was dynamically unloaded without unregistering.
10560 A COM allocation was leaked.
10561 Address of the leaked COM allocation. Run !heap -p -a <address> to get additional information about the allocation.
10562 Address to the allocation stack trace. Run dps <address> to view the allocation stack.
10563 Address of the owner dll name. Run du <address> to read the dll name.
10564 Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.
10566 This stop is generated if the owner dll of the COM allocation was dynamically unloaded while owning resources.
 

COM Classes/Interfaces

There is no type library in this file with COM classes/interfaces information

 

Exported Functions List

The following functions are exported by this dll:
AVrfAPILookupCallback VerifierAddFreeMemoryCallback
VerifierCheckPageHeapAllocation VerifierCreateRpcPageHeap
VerifierDeleteFreeMemoryCallback VerifierDestroyRpcPageHeap
VerifierDisableFaultInjectionExclusionRange VerifierDisableFaultInjectionTargetRange
VerifierEnableFaultInjectionExclusionRange VerifierEnableFaultInjectionTargetRange
VerifierEnumerateResource VerifierForceNormalHeap
VerifierGetInfoForException VerifierGetMemoryForDump
VerifierGetPropertyValueByName VerifierGetProviderHelper
VerifierIsAddressInAnyPageHeap VerifierIsCurrentThreadHoldingLocks
VerifierIsDllEntryActive VerifierIsPerUserSettingsEnabled
VerifierQueryRuntimeFlags VerifierRedirectStopFunctions
VerifierSetFaultInjectionProbability VerifierSetFlags
VerifierSetRuntimeFlags VerifierStopMessage

 

Imported Functions List

The following functions are imported by this dll: