I am trying to store the value in esp32 using preferences library when an interrupt is triggered.
Guru Meditation Error: Core 1 panic'ed (Interrupt wdt timeout on CPU1)
Core 1 register dump:
PC : 0x4008867a PS : 0x00060034 A0 : 0x80087a9b A1 : 0x3ffbe860
A2 : 0x3ffb7e0c A3 : 0x3ffb8074 A4 : 0x00000001 A5 : 0x00000001
A6 : 0x00060023 A7 : 0x00000000 A8 : 0x3ffb8074 A9 : 0x3ffb8074
A10 : 0x00000001 A11 : 0x00000001 A12 : 0x00000020 A13 : 0x0000ff00
A14 : 0x00ff0000 A15 : 0xff000000 SAR : 0x0000001e EXCCAUSE: 0x00000006
EXCVADDR: 0x00000000 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0xffffffff
Core 1 was running in ISR context:
EPC1 : 0x40085d07 EPC2 : 0x00000000 EPC3 : 0x00000000 EPC4 : 0x4008867a
ELF file SHA256: 0000000000000000
Backtrace: 0x4008867a:0x3ffbe860 0x40087a98:0x3ffbe880 0x400860cf:0x3ffbe8a0 0x400e2f42:0x3ffbe8e0 0x400e300a:0x3ffbe900 0x40083cad:0x3ffbe920 0x400840c4:0x3ffbe940 0x400e7b01:0x3ffbe990 0x400e5f66:0x3ffbe9b0 0x400e629e:0x3ffbe9d0 0x400e5a92:0x3ffbea50 0x400e4a77:0x3ffbeac0 0x400e4e55:0x3ffbeb10 0x400d1fa4:0x3ffbeb30 0x40080ecd:0x3ffbeb50 0x40080f19:0x3ffbeb70 0x40083969:0x3ffbeb90 0x40081b46:0x3ffb1e00 0x400826ef:0x3ffb1e20 0x40081183:0x3ffb1e40 0x400811a7:0x3ffb1e60 0x400d1cb7:0x3ffb1e80 0x400d1c85:0x3ffb1ea0 0x400d1c30:0x3ffb1ec0 0x400ebb35:0x3ffb1ee0 0x400ebbfe:0x3ffb1f00 0x400d1795:0x3ffb1f30 0x400d18da:0x3ffb1f70 0x400d1b47:0x3ffb1f90 0x400d33e9:0x3ffb1fb0 0x40086295:0x3ffb1fd0
Core 0 register dump:
PC : 0x40086729 PS : 0x00060034 A0 : 0x80086bd6 A1 : 0x3ffbc020
A2 : 0x3ffbdf74 A3 : 0xb33fffff A4 : 0x00060023 A5 : 0x003fffff
A6 : 0x00060021 A7 : 0x00000000 A8 : 0x0000abab A9 : 0x0000cdcd
A10 : 0x0000abab A11 : 0x00060023 A12 : 0x00060021 A13 : 0x3ffbc0d0
A14 : 0x00000003 A15 : 0x00060b23 SAR : 0x00000013 EXCCAUSE: 0x00000006
EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000
ELF file SHA256: 0000000000000000
Backtrace: 0x40086729:0x3ffbc020 0x40086bd3:0x3ffbc050 0x40088524:0x3ffbc070 0x400884da:0x3ffbc090 0x400893fb:0x00000000
Rebooting...
But I am getting this error when the interrupt is triggered. Please help me to resolve this
It's difficult to be sure as you didn't share any code, but... you should not update Preferences from an ISR. In fact unless you really really know what you're doing, you should do as little as possible inside an ISR.
Interrupts happen unpredictably... they literally interrupt whatever code is currently executing on the CPU. That means that any data structures the code is currently changing can be in an inconsistent state. Calling a function from the interrupt handler that uses those data structures will lead to data corruption and likely a crash.
Unless you wrote the code you're calling, you don't know what it calls. So you may say "it's okay, I'm not using Preferences outside the ISR" but you don't know what other functions Preferences calls.
You may get lucky and it may work at times... and it may also just crash randomly.
Again, unless you really really know what you're doing, there are very few functions that are safe to call inside an ISR. These are generally FreeRTOS functions that are explicitly designated as safe.
Interrupt handlers also block the CPU from doing other things it needs to do, so (unless you really really know what you're doing) you should minimize the amount of time you spend in the handler.
For most people who don't have experience writing interrupt handlers (especially people coding with the Arduino core), the best thing to do is the minimal work possible and set a flag that loop() inspects, and do the work in loop().
It's important that the flag be declared with the volatile keyword so that the compiler knows that its value can be changed unexpectedly.
It's also important that the interrupt handler be declared with IRAM_ATTR, to tell the system to keep its code loaded in instruction RAM so that it will be available when needed. Otherwise your program will crash if the code for the interrupt handler hasn't already been fetched from flash memory.
For instance:
volatile boolean interrupt_happened = false;
IRAM_ATTR void interrupt_handler() {
interrupt_happened = true;
}
void loop() {
if(interrupt_happened) {
do_some_work();
interrupt_happened = false;
}
}
Related
I'm developing a complex and intricate app for STM32F746. I stumbled upon the following hard fault and I'm not sure how to find the origin of the problem :
16:05:51.832 HardFault : ExceptionFrame { r0: 0xffffffff, r1: 0xffffffff, r2: 0xffffffff, r3: 0xffffffff, r12: 0xffffffff, lr: 0xffffffff, pc: 0xffffffff, xpsr: 0xffffffff }
16:05:51.832 UFSR : 0000000000000000
16:05:51.832 BFSR : 00000000
16:05:51.832 MMFSR : 00000001
16:05:51.832 HFSR : 01000000000000000000000000000000
The MMFSR part of the CFSR clearly indicates the error is IACCVIOL. Unfortunately, MMARVALID is not set, so I can't use the MMFAR to find the root of the issue.
Stepping through with GDB takes a huge amount of time for very little progress, as I need to start over every time the fault appears. I couldn't find a way to record/replay the session to quickly track down the issue in GDB.
Is there an approach that could help me pinpoint where the code fails ?
I am facing some data abort in u-boot and not able to find the root cause the issue. Can some tell me the ways how we can trace logs here or how to debug and decode these logs.
In u-boot which file gives the required details-
Below is the crash logs-:
data abort
pc : [<fff3fcb8>] lr : [<1a000018>]
reloc pc : [<B30017cb8>] lr : [<4a0d8018>]
sp : fdf17e5c ip : fff88a6c fp : 00000017
r10: 30061f88 r9 : fdf17ef8 r8 : fdf18a78
r7 : 00000010 r6 : 00000028 r5 : fdf3d138 r4 : 17f18ab8
r3 : fdf18a88 r2 : 00000018 r1 : fdf18aa0 r0 : 00000000
Flags: nzCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
BR,Abhi
First you need to disassemble the U-Boot file. Which version of objdump you need depends on your host and destination architecture, e.g.
arm-linux-gnueabihf-objdump -sD u-boot > u-boot.txt
Then look for the reloc pc address.
I got blue screen of death (bsod) error on my laptop some time ago. I read online that analyzing minidump file in "c:\windows\minidump" will help understand cause behind bsod error. (and probably point to the culprit driver causing the error)
I used this online tool to analyze error http://www.osronline.com/page.cfm?name=analyze
It created a report but I do not understand it. If you can understand it, please let me know.
Link to online crash analysis report: https://pastebin.com/raw/3Hhq7arw
Dump file location: https://drive.google.com/file/d/0BzNdoGke8tyRZk5YcHBKQV8ycFE/view?usp=sharing
Laptop config: Windows 7, 32 bit
You get an WHEA_UNCORRECTABLE_ERROR (124) Bugcheck, which measn there is a fatal hardware error:
The WHEA_UNCORRECTABLE_ERROR bug check has a value of 0x00000124. This
bug check indicates that a fatal hardware error has occurred.
Using the !errrec command in Windbg and the value from parameter 2 I see you have an Internal timer issue with your Intel i3-3217U CPU:
===============================================================================
Common Platform Error Record # 8a0a401c
-------------------------------------------------------------------------------
Record Id : 01d1ff7437bf4c24
Severity : Fatal (1)
Length : 928
Creator : Microsoft
Notify Type : Machine Check Exception
Timestamp : 8/26/2016 8:32:29 (UTC)
Flags : 0x00000000
===============================================================================
Section 0 : Processor Generic
-------------------------------------------------------------------------------
Descriptor # 8a0a409c
Section # 8a0a4174
Offset : 344
Length : 192
Flags : 0x00000001 Primary
Severity : Fatal
Proc. Type : x86/x64
Instr. Set : x86
Error Type : Micro-Architectural Error
Flags : 0x00
CPU Version : 0x00000000000306a9
Processor ID : 0x0000000000000003
===============================================================================
Section 1 : x86/x64 Processor Specific
-------------------------------------------------------------------------------
Descriptor # 8a0a40e4
Section # 8a0a4234
Offset : 536
Length : 128
Flags : 0x00000000
Severity : Fatal
Local APIC Id : 0x0000000000000003
CPU Id : a9 06 03 00 00 08 10 03 - bf e3 ba 3d ff fb eb bf
00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
Proc. Info 0 # 8a0a4234
===============================================================================
Section 2 : x86/x64 MCA
-------------------------------------------------------------------------------
Descriptor # 8a0a412c
Section # 8a0a42b4
Offset : 664
Length : 264
Flags : 0x00000000
Severity : Fatal
Error : Internal timer (Proc 3 Bank 3)
Status : 0xbe00000000800400
Address : 0x0000000085286f3c
Misc. : 0x0000000000000000
I see that you use the ASUS X550CA Laptop:
BiosVersion = X550CA.217
BiosReleaseDate = 01/23/2014
SystemManufacturer = ASUSTeK COMPUTER INC.
SystemProductName = X550CA
I see you se the older BIOS Version .217, so update the BIOS to .300, maybe it fixes the issue. If this doesn't fix the issue, do a stress test of the CPU with Prime95 and Intel CPU Diag tool.
I'm compiling a very simple hello-world one-liner statically on Debian 7 system on x86_64 machine with gcc version 4.8.2 (Debian 4.8.2-21):
gcc test.c -static -o test
and I get an executable ELF file that includes the following sections:
[17] .tdata PROGBITS 00000000006b4000 000b4000
0000000000000020 0000000000000000 WAT 0 0 8
[18] .tbss NOBITS 00000000006b4020 000b4020
0000000000000030 0000000000000000 WAT 0 0 8
[19] .init_array INIT_ARRAY 00000000006b4020 000b4020
0000000000000010 0000000000000000 WA 0 0 8
[20] .fini_array FINI_ARRAY 00000000006b4030 000b4030
0000000000000010 0000000000000000 WA 0 0 8
[21] .jcr PROGBITS 00000000006b4040 000b4040
0000000000000008 0000000000000000 WA 0 0 8
[22] .data.rel.ro PROGBITS 00000000006b4060 000b4060
00000000000000e4 0000000000000000 WA 0 0 32
Note that .tbss section is allocated at addresses 0x6b4020..0x6b4050 (0x30 bytes) and it intersects with allocation of .init_array section at 0x6b4020..0x6b4030 (0x10 bytes), .fini_array section at 0x6b4030..0x6b4040 (0x10 bytes) and with .jcr section at 0x6b4040..0x6b4048 (8 bytes).
Note it does not intersect with the following sections, for example, .data.rel.ro, but that's probably because .data.rel.ro alignment is 32 and thus it can't be placed any earlier than 0x6b4060.
The resulting file runs ok, but I still don't exactly get how it works. From what I read in glibc documentation, .tbss is a just .bss section for thread local storage (i.e. allocated memory scratch space, not really mapped in physical file). Is it that .tbss section is so special that it can overlap other sections? Are .init_array, .fini_array and .jcr are so useless (for example, they are not needed anymore then TLS-related code runs), so they can be overwritten by bss? Or is it some sort of a bug?
Basically, what do I get to read and write if I'll try to read address 0x6b4020 in my application? .tbss contents or .init_array pointers? Why?
The virtual address of .tbss is meaningless as that section only serves as a template for the TLS storage as allocated by the threading implementation in GLIBC.
The way this virtual address comes into place is that .tbss follows .tbdata in the default linker script:
...
.gcc_except_table : ONLY_IF_RW { *(.gcc_except_table .gcc_except_table.*) }
/* Thread Local Storage sections */
.tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
.tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
.preinit_array :
{
PROVIDE_HIDDEN (__preinit_array_start = .);
KEEP (*(.preinit_array))
PROVIDE_HIDDEN (__preinit_array_end = .);
}
.init_array :
{
PROVIDE_HIDDEN (__init_array_start = .);
KEEP (*(SORT(.init_array.*)))
KEEP (*(.init_array))
PROVIDE_HIDDEN (__init_array_end = .);
}
...
therefore its virtual address is simply the virtual address of the preceding section (.tbdata) plus the size of the preceding section (eventually with some padding in order to reach the desired alignment). .init_array (or .preinit_array if present) comes next and its location should be determined the same way, but .tbss is known to be so very special, that it is given a deeply hard-coded treatment inside GNU LD:
/* .tbss sections effectively have zero size. */
if ((os->bfd_section->flags & SEC_HAS_CONTENTS) != 0
|| (os->bfd_section->flags & SEC_THREAD_LOCAL) == 0
|| link_info.relocatable)
dotdelta = TO_ADDR (os->bfd_section->size);
else
dotdelta = 0; // <----------------
dot += dotdelta;
.tbss is not relocatable, it has the SEC_THREAD_LOCAL flag set, and it does not have contents (NOBITS), therefore the else branch is taken. In other words, no matter how large the .tbss is, the linker does not advance the location of the section that follows it (also know as "the dot").
Note also that .tbss sits in a non-loadable ELF segment:
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x00000000000b1f24 0x00000000000b1f24 R E 200000
LOAD 0x00000000000b2000 0x00000000006b2000 0x00000000006b2000
0x0000000000002288 0x00000000000174d8 RW 200000
NOTE 0x0000000000000158 0x0000000000400158 0x0000000000400158
0x0000000000000044 0x0000000000000044 R 4
TLS 0x00000000000b2000 0x00000000006b2000 0x00000000006b2000 <---+
0x0000000000000020 0x0000000000000060 R 8 |
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 |
0x0000000000000000 0x0000000000000000 RW 8 |
|
Section to Segment mapping: |
Segment Sections... |
00 .note.ABI-tag ... |
01 .tdata .ctors ... |
02 .note.ABI-tag ... |
03 .tdata .tbss <---------------------------------------------------+
04
This is rather simple if you have an understanding about two things:
1) What is SHT_NOBITS
2) What is tbss section
SHT_NOBITS means that this section occupies no space inside file.
Normally, NOBITS sections, like bss are placed after all PROGBITS sections at the end of the loaded segments.
tbss is special section to hold uninitialized thread-local data that contribute to the program's memory image. Take an attention here: this section must hold unique data for each program thread.
Now lets talk about overlapping. We have two possible overlappings -- inside binary file and inside memory.
1) Binary files offset:
There is no data to write under this section in binary. Inside file it holds no space, so linker start next section init_array immediately after tbss declared. You may think about its size not as about size, but as about special service information for code like:
if (isTLSSegment) tlsStartAddr += section->memSize();
So it doesn't overlap anything inside file.
2) Memory offset
The tdata and tbss sections may be possibly modified at startup time by the dynamic linker
performing relocations, but after that the section data is kept around as the initialization image and not modified anymore. For each thread, including the initial one, new memory is allocated into which then the content of the initialization image is copied. This ensures that all threads get the same starting conditions.
This what makes tbss (and tdata) so special.
Do not think about their memory offsets as about statically known -- they are more like "generation patterns" for per-thread work. So they also can not overlap with "normal" memory offsets -- they are being processed in other way.
You may consult with this paper to know more.
This one is stumping me.
My driver works perfectly fine in all of the guest virtual systems (Windows xp/7 both x86 and x64), as well as a few certain hosts.
However, on my PC I'm receiving a 0x7E stop code right as I start up the driver in OSRLoader.
Yes, Testsigning and debug mode are both enabled.
Here is some dump information (warning, huge):
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: ffffffff80000003, The exception code that was not handled
Arg2: fffff88000c0af0f, The address that the exception occurred at
Arg3: fffff88002fb1d78, Exception Record Address
Arg4: fffff88002fb15e0, Context Record Address
Debugging Details:
------------------
EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid
FAULTING_IP:
CI!CiValidateImageHeader+167
fffff880`00c0af0f cc int 3
EXCEPTION_RECORD: fffff88002fb1d78 -- (.exr 0xfffff88002fb1d78)
ExceptionAddress: fffff88000c0af0f (CI!CiValidateImageHeader+0x0000000000000167)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 1
Parameter[0]: 0000000000000000
CONTEXT: fffff88002fb15e0 -- (.cxr 0xfffff88002fb15e0)
rax=0000000000000000 rbx=00000000000000ff rcx=1748c3f2dac60000
rdx=0000000000000008 rsi=fffff88002fb2100 rdi=00000000c0000428
rip=fffff88000c0af0f rsp=fffff88002fb1fb0 rbp=0000000000000000
r8=0000000000000001 r9=fffff80002d0bbe0 r10=fffff80002e4a900
r11=fffff88002fb1fa8 r12=0000000000006000 r13=fffff98018700000
r14=fffffa8002621520 r15=0000000000000001
iopl=0 nv up ei ng nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000282
CI!CiValidateImageHeader+0x167:
fffff880`00c0af0f cc int 3
Resetting default scope
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0x7E
PROCESS_NAME: System
CURRENT_IRQL: 0
ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached.
EXCEPTION_PARAMETER1: 0000000000000000
LAST_CONTROL_TRANSFER: from fffff80002f35b18 to fffff88000c0af0f
STACK_TEXT:
fffff880`02fb1fb0 fffff800`02f35b18 : 00000000`00000006 00000000`000fffff fffffa80`02621520 00000000`00000000 : CI!CiValidateImageHeader+0x167
fffff880`02fb2090 fffff800`02f3591a : 00000000`00000000 00000000`01000000 fffffa80`055e6010 00000000`00000000 : nt!SeValidateImageHeader+0x58
fffff880`02fb20d0 fffff800`0302dea2 : fffffa80`02621520 fffffa80`055e6010 00000000`00000001 00000000`00000006 : nt!MiValidateImageHeader+0x21a
fffff880`02fb21a0 fffff800`02fba3cf : fffff880`02fb2400 00000000`00000000 fffff880`02fb26b8 fffff880`02fb23f8 : nt! ?? ::NNGAKEGL::`string'+0x4e3e3
fffff880`02fb23b0 fffff800`02cce293 : fffffa80`02505b60 fffff880`02fb2658 fffff880`02fb2448 00000000`00000000 : nt!NtCreateSection+0x162
fffff880`02fb2430 fffff800`02cca830 : fffff800`030a7f16 00000000`00000000 fffff800`02fbc607 00000000`00000001 : nt!KiSystemServiceCopyEnd+0x13
fffff880`02fb2638 fffff800`030a7f16 : 00000000`00000000 fffff800`02fbc607 00000000`00000001 fffffa80`0254c518 : nt!KiServiceLinkage
fffff880`02fb2640 fffff800`030a82dc : ffffffff`80000ea4 fffffa80`00100000 fffffa80`0254c518 00000000`00000000 : nt!MmCheckSystemImage+0x96
fffff880`02fb2770 fffff800`030a84f7 : ffffffff`80000ea4 fffff800`00000001 fffff8a0`0b36c500 00000000`00000000 : nt!MiCreateSectionForDriver+0xcc
fffff880`02fb2820 fffff800`030b3d9a : 00000000`00000000 fffff880`02fb29f8 fffffa80`02505b60 fffff800`02e48e00 : nt!MiObtainSectionForDriver+0xd7
fffff880`02fb2880 fffff800`030b69bd : fffff880`02fb29f8 00000000`00000000 00000000`00000000 00000000`00000000 : nt!MmLoadSystemImage+0x23a
fffff880`02fb29a0 fffff800`030b7375 : 00000000`00000001 00000000`00000000 00000000`00000000 fffffa80`02829388 : nt!IopLoadDriver+0x44d
fffff880`02fb2c70 fffff800`02cdc1e1 : fffff8a0`00000000 ffffffff`80000e90 fffff800`030b7320 fffffa80`02505b60 : nt!IopLoadUnloadDriver+0x55
fffff880`02fb2cb0 fffff800`02f6e6e6 : b9ce705b`ee973fcb fffffa80`02505b60 00000000`00000080 fffffa80`024ef5f0 : nt!ExpWorkerThread+0x111
fffff880`02fb2d40 fffff800`02cad566 : fffff880`009eb180 fffffa80`02505b60 fffff880`009f5f40 50320c1b`3fdc0847 : nt!PspSystemThreadStartup+0x5a
fffff880`02fb2d80 00000000`00000000 : fffff880`02fb3000 fffff880`02fad000 fffff880`02fb13f0 00000000`00000000 : nt!KiStartSystemThread+0x16
FOLLOWUP_IP:
CI!CiValidateImageHeader+167
fffff880`00c0af0f cc int 3
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: CI!CiValidateImageHeader+167
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: CI
IMAGE_NAME: CI.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 4a5be01d
STACK_COMMAND: .cxr 0xfffff88002fb15e0 ; kb
FAILURE_BUCKET_ID: X64_0x7E_CI!CiValidateImageHeader+167
BUCKET_ID: X64_0x7E_CI!CiValidateImageHeader+167
Followup: MachineOwner
---------
As the little bit at the top states, I have booted with /DEBUG on and it shows nothing more than I already have.
The first log in my code doesn't even get hit:
/*
* DriverEntry
* Driver entry point
*/
NTSTATUS DriverEntry(IN PDRIVER_OBJECT driver, IN PUNICODE_STRING path)
{
// Setup vars
UNICODE_STRING devLink, devName;
PDEVICE_OBJECT devObj = NULL;
NTSTATUS ntsReturn;
// Log Entry
LOG("Driver Entry");
// Setup driver unload function
driver->DriverUnload = DrvUnload;
WinDbg shows nothing of the sort in its view.
How do I know what is causing this? The breakpoint causes a BSOD when windbg isn't attached, and (obviously) freezes my computer when it is attached, giving me no real usable data.
It looks like you hit a debug assert in CI.dll. You can just type g from the debugger and continue loading your driver.
That is the default behavior of x64 builds of Windows. If you don't want to see that assertion you have to F8 at boot time and select "Disable Driver Signature Enforcement" which is valid per boot. (You have to do it every time you restart). Or, you can use 32-bit Windows and 32-bit version of your driver for debugging.
Here is more info:
http://msdn.microsoft.com/en-us/library/ff547565(v=vs.85).aspx