I'm on Windows 7 SP1 64-bit. In WinDBG, I open an executable and then enter the command
!slist $teb _EXCEPTION_REGISTRATION_RECORD 0
but here's what I get:
SLIST HEADER:
+0x000 Header8.Sequence : fd
+0x000 Header8.Depth : d000
+0x008 Region : 0
SLIST CONTENTS:
00000000001d0110
+0x000 Next : ????
+0x008 Handler : ????
Can't read memory at 00000000001d0110, error 0
I don't understand what's wrong.
edit: I'm trying to display the exception handler chain manually. If I enter
!exchain
everything works fine:
4 stack frames, scanning for handlers...
Frame 0x00: ntdll!LdrpDoDebuggerBreak+0x30 (00000000`7787cb70)
ehandler ntdll!_C_specific_handler (00000000`777e852c)
Frame 0x01: ntdll!LdrpInitializeProcess+0x17c7 (00000000`77832bed)
ehandler ntdll!_GSHandlerCheck (00000000`777e9840)
Frame 0x02: ntdll! ?? ::FNODOBFM::`string'+0x28ff0 (00000000`77811937)
ehandler ntdll!_C_specific_handler (00000000`777e852c)
That happens when one uses the 64-bit version of WinDBG to debug 32-bit executables. It's better to install both versions of WinDBG and use the 32-bit version for debugging 32-bit apps.
Related
I am new to using windbg, and I am trying to set a breakpoint inside of the main function of a .net assembly that I am trying to debug, but am getting:
Unable to insert breakpoint 0 at 000001d1`4465384e, Win32 error 0n998 "Invalid access to memory location."
I have tried using bp and bu $exentry to set a break point for the entry to the program, but even that is giving me the same error. I've tried searching other old stackoverflow topics on this issue and through google, but still haven't found a solution.
Any help would be greatly appreciated.
Given a trivial .NET Console application compiled for .NET framework 4.7
using System;
namespace DebugNetMainMethod
{
class Program
{
static void Main()
{
Console.WriteLine("If you can read this, it's too late. You wanted to set a breakpoint earlier.");
Console.ReadLine();
}
}
}
you can use WinDbg Preview to debug it.
Run WinDbg Preview
Choose "Launch Executable" and select the EXE
WinDbg will stop at the initial breakpoint
ntdll!LdrpDoDebuggerBreak+0x2b:
7743ecc2 cc int 3
At this point, you get the problem you described:
0:000> bp $exentry
0:000> bl
0 e Disable Clear 007a27c6 0001 (0001) 0:**** DebugNetMainMethod!COM+_Entry_Point <PERF> (DebugNetMainMethod+0x27c6)
0:000> g
Unable to insert breakpoint 0 at 007a27c6, Win32 error 0n998
"Invalid access to memory location."
0:000> bc 0
0:000> bl
Note: In the future you want to provide exactly the information above, so everyone can reproduce your issue.
WinDbg is not made for .NET but for debugging "native code", i.e. code that was compiled for a specific processor like x86 or AMD64. WinDbg does not work well for Java, Python or .NET. However, for .NET, Microsoft provides an extension called SOS. You would typically load it like this:
0:000> .loadby sos clr
Unable to find module 'clr'
But at this early stage of debugging, not many DLLs have been loaded and the clr is still missing. So let's postpone this:
0:000> sxe ld clrjit
0:000> g
[...]
ModLoad: 72950000 729da000 C:\Windows\Microsoft.NET\Framework\v4.0.30319\clrjit.dll
[...]
0:000> .loadby sos clr
No output means it worked.
0:000> !bpmd DebugNetMainMethod Program.Main
Found 1 methods in module 00914044...
MethodDesc = 00914d5c
Adding pending breakpoints...
0:000> g
[...]
(2658.2e08): CLR notification exception - code e0444143 (first chance)
JITTED DebugNetMainMethod!DebugNetMainMethod.Program.Main()
Setting breakpoint: bp 00BA085F [DebugNetMainMethod.Program.Main()]
Breakpoint 2 hit
0:000> !clrstack
OS Thread Id: 0x2e08 (0)
Child SP IP Call Site
0075eff4 00ba085f DebugNetMainMethod.Program.Main() [C:\...\Program.cs # 8]
0075f170 63dff036 [GCFrame: 0075f170]
0:000> !u eip
Normal JIT generated code
DebugNetMainMethod.Program.Main()
Begin 00ba0848, size 32
[...]
for studying Qemu I got the 'QEMU Eclipse' plugin, built the 'blinky' project from https://gnu-mcu-eclipse.github.io/tutorials/blinky-arm/ and when I let it run, it produces the following output:
xPack 64-bit QEMU v2.8.0-9 (qemu-system-gnuarmeclipse).
Board: 'STM32F4-Discovery' (ST Discovery kit for STM32F407/417 lines).
Board picture: '/home/hgiese/Work/qemu-arm-dev/linux-x64/install/qemu-arm/share/qemu/graphics/STM32F4-Discovery.jpg'.
Device file: '/home/hgiese/Work/qemu-arm-dev/linux-x64/install/qemu-arm/share/qemu/devices/STM32F40x-qemu.json'.
Device: 'STM32F407VG' (Cortex-M4 r0p0, MPU, 4 NVIC prio bits, 82 IRQs), Flash: 1024 kB, RAM: 128 kB.
Command line: 'blinky' (6 bytes).
...
and when I let it run everything was fine.
Now, when I called Qemu directly (outside of Eclipse) with the exact command line the output was this:
xPack 64-bit QEMU v2.8.0-9 (qemu-system-gnuarmeclipse).
Board: 'STM32F4-Discovery' (ST Discovery kit for STM32F407/417 lines).
Board picture: '/home/hgiese/Work/qemu-arm-dev/linux-x64/install/qemu-arm/share/qemu/graphics/STM32F4-Discovery.jpg'.
Device file: '/home/hgiese/Work/qemu-arm-dev/linux-x64/install/qemu-arm/share/qemu/devices/STM32F40x-qemu.json'.
Device: 'STM32F407VG' (Cortex-M4 r0p0, MPU, 4 NVIC prio bits, 82 IRQs), Flash: 1024 kB, RAM: 128 kB.
Command line: 'blinky' (6 bytes).
qemu-system-gnuarmeclipse: Guest image must be specified (using --image)
no matter how I specified 'blinky':
being in the Debug directory
calling it as blinky.elf
calling it with its complete path
It got even stranger: In an attempt to produce an error message from Qemu (which might tell me something) I replaced 'blinky' with 'xyz' (in the command line field of the 'Debugger' pane in the 'Debug Configuration' dialog) - and it still worked. The only difference being the line
Command line: 'xyz' (3 bytes).
in Qemu's output, which showed me that Qemu had received this dummy parameter - and it didn't make the slightest difference for it: it still had the correct image file.
How do I have to communicate the image file to Qemu (or 'How does Eclipse does its magic?')
Any insight will be greatly appreciated.
Helmut
I have a code in Fortran (program.f) and I have compiled it with Eclipse in \ubuntu 16 and in Windows 7.
The Eclipse configuration for Ubuntu is the follow:
GNU Fortran Compiler: gfortran
Include paths(-l) : /usr/lib/openmpi/include
GNU Fortran Linker : mpif90
Tool Chain Editor : GCC Fortran
The Eclipse configuration for Windows is the follow:
GNU Fortran Compiler: gfortran
Include paths(-l) : C:\cygwin64\usr\include
GNU Fortran Linker : mpif90
Tool Chain Editor : GCC Fortran
When I execute the program in Ubuntu, the program works how it is expected.
In Ubuntu the program is executed with 2 processors by doing
$ mpiexec -np 2 myprogram
And the behavior is the follow
$ mpiexec -np 2 myprogram
There are 2 processors running this job.
Rank# 1 d1= 65 d2= 128
Rank# 0 d1= 1 d2= 64
Where d1 and d2 are pieces of the problem domain assigned to each processors. In this example the total domain is 128. The domain was assigned from 1 to 64 to processor 0, and from 65 to 128 to processor 1. This is the expected behavior: the model of 128 are divided in 2, from 1 to 64 to processor 0, and from 65 to 128 for the processor 1.
For the other hand, in Windows, after compile the code using the mentioned specifications, I execute the program by doing:
$ mpiexec.exe -n 2 myprogram.exe
And the behavior is the follow
$ mpiexec -np 2 myprogram
There are 1 processors running this job.
Rank# 0 d1= 1 d2= 128
Rank# 0 d1= 1 d2= 128
We can see that the behavior is different: the program executed in Windows is not running in parallel as it is expected. In the terminal we can see that 1 processor is running the program, and the domain is assigned as follow: from 1 to 128 (whole domain) to processor 0 and, from 1 to 128 (whole domain again?) to processor 0. This is the problem that I am trying to solve. I am trying to have the same behavior that I have in Ubuntu.
The mpiexec.exe program for Windows was obtained from the official installer MS-MPI.
The gfortran and the OpenMPI libs for Windows were obtained by using cygwin
I tried to change the GNU linker and the compiler in Eclipse for Windows and does not work. I tried to run the code in others machines with Windows 10 and problem is the same.
Any suggestions on how to try solve this issue?
As mentioned by #jcgiret there are a consistency problem: the program is compiled using OpenMPI and it is executed with MS-MPI.
To solve this issue the code was executed using the equivalent to mpiexec defined in the openmpi package:
usr/bin/mpiexec -> orterun.exe
The program is executed in windows by
$ orterun.exe -n 2 myprogram.exe
Then the results is the same that obtained in Ubuntu:
$ orterun.exe -n 2 myprogram.exe
There are 2 processors running this job.
Rank# 1 d1= 65 d2= 128
Rank# 0 d1= 1 d2= 64
I'm attempting to debug a manual dump file of a 64bit w3wp process with 64bit Windbg (Version 6.10). The dump was taken with taskmgr. I can't get anything from the !clrstack command. Here is what I'm getting:
!loadby sos clr
!runaway
User Mode Time
Thread Time
17:cf4 0 days 5:37:42.455
~17s
ntdll!ZwDelayExecution+0xa:
00000000`776208fa c3 ret
!clrstack
GetFrameContext failed: 1
What is GetFrameContext failed: 1?
Use !dumpstack command instead of !clrstack. It usually works.
Try getting the "native" call stack by doing "k" and see what that gets you. Sometimes, the stack isn't quite right and the !ClrStack extension is pretty sensitive.
The system include 2 Advantech PCI-1716 card:http://www.advantech.com/products/PCI-1716/mod_86EC4C4D-F497-45C5-81DA-B8600C0EB36F.aspx
I write a program with NI LabVIEW 7.1.
The LabVIEW program can control the two PCI 1716 card.
It work very good.
But about a year later, The computer crashed and sometimes auto restart.
Nobody change the software and hardware.
I used WinDbg to analysis the Windows crash dump file and I think I find something abnormal.
For the WinDbg result, I think maybe the PCI-1716 driver was broken so I re-installed it.
But the problem also happen.
And I also re-installed my windows xp.
The also problem happen again.
I don't know how.
Maybe the PCI 1716 hardware broken.
But how to find which one, there are two PCI 1716 card.
The WinDbg result is:
Loading Dump File [F:\WinDBG\Mini012313-01.dmp] Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: srv*C:\Documents and Settings\cky\symbols*http://msdl.microsoft.com/download/symbols Executable search path is: Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible Product: WinNt, suite: TerminalServer SingleUserTS Built by: 2600.xpsp_sp2_rtm.040803-2158 Kernel base = 0x804d8000 PsLoadedModuleList = 0x8055d700 Debug session time: Wed Jan 23 23:09:23.250 2013 (GMT+8) System Uptime: 0 days 23:47:48.802 Loading Kernel Symbols ....................................................................................................... Loading User Symbols Loading unloaded module list ....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 1000000A, {ffdf, 2, 1, 806e5a8e}
Unable to load image ADS1716S.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ADS1716S.sys
*** ERROR: Module load completed but symbols could not be loaded for ADS1716S.sys Probably caused by : ADS1716S.sys ( ADS1716S+f08 )
Followup: MachineOwner
---------
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
IRQL_NOT_LESS_OR_EQUAL (a) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. If a kernel debugger is available get the stack backtrace. Arguments: Arg1: 0000ffdf, memory referenced Arg2: 00000002, IRQL Arg3: 00000001, bitfield : bit 0 : value 0 = read operation, 1 = write operation bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status) Arg4: 806e5a8e, address which referenced memory
Debugging Details:
------------------
WRITE_ADDRESS: 0000ffdf
CURRENT_IRQL: 2
FAULTING_IP: hal!KeAcquireQueuedSpinLock+42 806e5a8e 8902 mov dword ptr [edx],eax
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xA
PROCESS_NAME: LabVIEW.exe
LAST_CONTROL_TRANSFER: from 804efbb0 to 806e5a8e
STACK_TEXT: aa286c00 804efbb0 aa286c20 804f0de4 aa286c1c hal!KeAcquireQueuedSpinLock+0x42 aa286c08 804f0de4 aa286c1c 8602dc38 806e53b8 nt!IoAcquireCancelSpinLock+0xe aa286c20 804f104a 8602dc38 00000001 aa286c58 nt!IopStartNextPacket+0x18 aa286c30 f788ef08 8602dc38 00000001 85eb0230 nt!IoStartNextPacket+0x38 WARNING: Stack unwind information not available. Following frames may be wrong. aa286c58 80575529 85eb0230 86090da0 85f32448 ADS1716S+0xf08 aa286c80 805d1cb9 85f32448 85f32448 85f32690 nt!IoCancelThreadIo+0x33 aa286d08 805d209a 00000001 85f32448 00000000 nt!PspExitThread+0x403 aa286d28 805d2275 85f32448 00000001 aa286d64 nt!PspTerminateThreadByPointer+0x52 aa286d54 8054160c 00000000 00000001 0012e810 nt!NtTerminateProcess+0x105 aa286d54 7c92eb94 00000000 00000001 0012e810 nt!KiFastCallEntry+0xfc 0012e810 00000000 00000000 00000000 00000000 0x7c92eb94
STACK_COMMAND: kb
FOLLOWUP_IP: ADS1716S+f08 f788ef08 ?? ???
SYMBOL_STACK_INDEX: 4
SYMBOL_NAME: ADS1716S+f08
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: ADS1716S
IMAGE_NAME: ADS1716S.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 45b96de9
FAILURE_BUCKET_ID: 0xA_W_ADS1716S+f08
BUCKET_ID: 0xA_W_ADS1716S+f08
Followup: MachineOwner
---------
0: kd> lmvm ADS1716S start end module name f788e000 f7893ac0 ADS1716S T (no symbols)
Loaded symbol image file: ADS1716S.sys
Image path: ADS1716S.sys
Image name: ADS1716S.sys
Timestamp: Fri Jan 26 10:56:41 2007 (45B96DE9)
CheckSum: 00010C75
ImageSize: 00005AC0
Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0
I'd run Memtest86+ just to see if you have any bad RAM.
Following that maybe you can pull 1 card out and write a simple script to do some I/O (similar to what you're doing normally maybe). If it takes a while you could put it into a loop and run it for a while and see if you can force a crash. You could repeat the test on each card to see if you have any issues with just one of the cards.
Does the crash happen often or rarely?