I'm using windbg to debug windows kernel files. The problem is that I know which function
to set break point but I don't know the module the function belongs. I use windows server
2019 and the module should be ntoskrnl from the import in IDA. I didn't find the module
in windbg somehow(maybe there is a alias). How do I know which module imports the
function or the address of the function?
The loaded modules are as follows
start end module name
ffffaa98`27400000 ffffaa98`2778b000 win32kfull (pdb symbols) C:\ProgramData\Dbg\sym\win32kfull.pdb\BD15EC0EDD344DABCC32F9C2E347B97B1\win32kfull.pdb
ffffaa98`27790000 ffffaa98`279ec000 win32kbase (deferred)
ffffaa98`279f0000 ffffaa98`27a38000 cdd (deferred)
ffffaa98`28300000 ffffaa98`2838b000 win32k (deferred)
fffff801`19c0e000 fffff801`19cab000 hal (deferred)
fffff801`19cac000 fffff801`1a71c000 nt (pdb symbols) C:\ProgramData\Dbg\sym\ntkrnlmp.pdb\45C12C294F739481AC5E8E014C068FB61\ntkrnlmp.pdb
fffff801`1a800000 fffff801`1a80e000 kdcom (deferred)
fffff80f`e7c00000 fffff80f`e7c70000 FLTMGR (deferred)
fffff80f`e7c80000 fffff80f`e7d8a000 clipsp (deferred)
fffff80f`e7d90000 fffff80f`e7d9e000 cmimcext (deferred)
fffff80f`e7da0000 fffff80f`e7dac000 ntosext (deferred)
fffff80f`e7db0000 fffff80f`e7e83000 CI (deferred)
fffff80f`e7e90000 fffff80f`e7f48000 cng (deferred)
fffff80f`e7f50000 fffff80f`e8021000 Wdf01000 (deferred)
fffff80f`e8030000 fffff80f`e8043000 WDFLDR (deferred)
fffff80f`e8050000 fffff80f`e8060000 WppRecorder (deferred)
fffff80f`e8070000 fffff80f`e807f000 SleepStudyHelper (deferred)
fffff80f`e8080000 fffff80f`e80a4000 acpiex (deferred)
fffff80f`e80b0000 fffff80f`e8101000 mssecflt (deferred)
fffff80f`e8110000 fffff80f`e812a000 SgrmAgent (deferred)
fffff80f`e8130000 fffff80f`e81f8000 ACPI (deferred)
fffff80f`e8200000 fffff80f`e8220000 mcupdate_AuthenticAMD (deferred)
fffff80f`e8230000 fffff80f`e8292000 msrpc (deferred)
fffff80f`e82a0000 fffff80f`e82cb000 ksecdd (deferred)
fffff80f`e82d0000 fffff80f`e82e1000 werkernel (deferred)
fffff80f`e82f0000 fffff80f`e835a000 CLFS (deferred)
fffff80f`e8360000 fffff80f`e8387000 tm (deferred)
fffff80f`e8390000 fffff80f`e83a8000 PSHED (deferred)
fffff80f`e83b0000 fffff80f`e83bb000 BOOTVID (deferred)
fffff80f`e83c0000 fffff80f`e83cc000 WMILIB (deferred)
fffff80f`e8400000 fffff80f`e8443000 intelpep (deferred)
fffff80f`e8450000 fffff80f`e845b000 WindowsTrustedRTProxy (deferred)
fffff80f`e8460000 fffff80f`e8474000 pcw (deferred)
fffff80f`e84a0000 fffff80f`e85f3000 NDIS (deferred)
fffff80f`e8600000 fffff80f`e8695000 NETIO (pdb symbols) C:\ProgramData\Dbg\sym\netio.pdb\C34301C2DC7F81959A5EF6C03D4BA3871\netio.pdb
fffff80f`e86a0000 fffff80f`e86ab000 msisadrv (deferred)
fffff80f`e86b0000 fffff80f`e86c2000 vdrvroot (deferred)
fffff80f`e86d0000 fffff80f`e873b000 pci (deferred)
fffff80f`e8740000 fffff80f`e876e000 pdc (deferred)
fffff80f`e8770000 fffff80f`e8789000 CEA (deferred)
fffff80f`e8790000 fffff80f`e87bf000 partmgr (deferred)
fffff80f`e87c0000 fffff80f`e87cb000 intelide (deferred)
fffff80f`e87d0000 fffff80f`e87e3000 PCIIDEX (deferred)
fffff80f`e87f0000 fffff80f`e8894000 spaceport (deferred)
fffff80f`e88a0000 fffff80f`e88b9000 volmgr (deferred)
fffff80f`e88c0000 fffff80f`e8923000 volmgrx (deferred)
fffff80f`e8930000 fffff80f`e894f000 mountmgr (deferred)
fffff80f`e8950000 fffff80f`e895d000 atapi (deferred)
fffff80f`e8960000 fffff80f`e8996000 ataport (deferred)
fffff80f`e89a0000 fffff80f`e89bc000 EhStorClass (deferred)
fffff80f`e89c0000 fffff80f`e89fe000 Wof (deferred)
fffff80f`e8a00000 fffff80f`e8a15000 dfsrro (deferred)
fffff80f`e8a20000 fffff80f`e8a92000 WdFilter (deferred)
fffff80f`e8aa0000 fffff80f`e8b0d000 volsnap (deferred)
fffff80f`e8b10000 fffff80f`e8b7f000 CLASSPNP (deferred)
fffff80f`e8b80000 fffff80f`e8b95000 filecrypt (deferred)
fffff80f`e8ba0000 fffff80f`e8bb6000 WindowsTrustedRT (deferred)
fffff80f`e8bc0000 fffff80f`e8bd4000 dfs (deferred)
fffff80f`e8be0000 fffff80f`e8bea000 Null (deferred)
fffff80f`e8c20000 fffff80f`e8c4e000 cdrom (deferred)
fffff80f`e8c50000 fffff80f`e8c5e000 tbs (deferred)
fffff80f`e8c60000 fffff80f`e8eed000 Ntfs (deferred)
fffff80f`e8ef0000 fffff80f`e8f48000 VBoxGuest (deferred)
fffff80f`e8f50000 fffff80f`e8f5d000 Fs_Rec (deferred)
fffff80f`e8f60000 fffff80f`e8f92000 ksecpkg (deferred)
fffff80f`e8fa0000 fffff80f`e8fbc000 disk (deferred)
fffff80f`e8fc0000 fffff80f`e8fdc000 crashdmp (deferred)
fffff80f`e9000000 fffff80f`e9078000 fwpkclnt (deferred)
fffff80f`e9080000 fffff80f`e90b0000 wfplwfs (deferred)
fffff80f`e90c0000 fffff80f`e90cb000 volume (deferred)
fffff80f`e90d0000 fffff80f`e90f5000 mup (deferred)
fffff80f`e9120000 fffff80f`e93fa000 tcpip (deferred)
fffff80f`e9a00000 fffff80f`e9a51000 netbt (deferred)
fffff80f`e9a60000 fffff80f`e9a73000 afunix (deferred)
fffff80f`e9a80000 fffff80f`e9b26000 afd (deferred)
fffff80f`e9b30000 fffff80f`e9b5b000 pacer (deferred)
fffff80f`e9b60000 fffff80f`e9b74000 netbios (deferred)
fffff80f`e9bc0000 fffff80f`e9efb000 dxgkrnl (deferred)
fffff80f`e9f00000 fffff80f`e9f16000 watchdog (deferred)
fffff80f`e9f20000 fffff80f`e9f36000 BasicDisplay (deferred)
fffff80f`e9f40000 fffff80f`e9f51000 BasicRender (deferred)
fffff80f`e9f60000 fffff80f`e9f7c000 Npfs (deferred)
fffff80f`e9f80000 fffff80f`e9f91000 Msfs (deferred)
fffff80f`e9fa0000 fffff80f`e9fc7000 tdx (deferred)
fffff80f`e9fd0000 fffff80f`e9fe0000 TDI (deferred)
fffff80f`ea000000 fffff80f`ea04e000 ahcache (deferred)
fffff80f`ea050000 fffff80f`ea061000 CompositeBus (deferred)
fffff80f`ea070000 fffff80f`ea07d000 kdnic (deferred)
fffff80f`ea080000 fffff80f`ea095000 umbus (deferred)
fffff80f`ea0a0000 fffff80f`ea0c1000 i8042prt (deferred)
fffff80f`ea0d0000 fffff80f`ea0e3000 kbdclass (deferred)
fffff80f`ea0f0000 fffff80f`ea13a000 VBoxMouse (deferred)
fffff80f`ea140000 fffff80f`ea153000 mouclass (deferred)
fffff80f`ea160000 fffff80f`ea1d6000 VBoxWddm (deferred)
fffff80f`ea1e0000 fffff80f`ea204080 E1G6032E (deferred)
fffff80f`ea210000 fffff80f`ea21f000 usbohci (deferred)
fffff80f`ea220000 fffff80f`ea29b000 USBPORT (deferred)
fffff80f`ea2a0000 fffff80f`ea2af000 CmBatt (deferred)
fffff80f`ea2b0000 fffff80f`ea2c0000 BATTC (deferred)
fffff80f`ea2d0000 fffff80f`ea30a000 amdppm (deferred)
fffff80f`ea310000 fffff80f`ea31d000 NdisVirtualBus (deferred)
fffff80f`ea320000 fffff80f`ea32c000 swenum (deferred)
fffff80f`ea330000 fffff80f`ea3a5000 ks (deferred)
fffff80f`ea3b0000 fffff80f`ea3be000 rdpbus (deferred)
fffff80f`ea3c0000 fffff80f`ea448000 usbhub (deferred)
fffff80f`ea450000 fffff80f`ea45e000 USBD (deferred)
fffff80f`ea460000 fffff80f`ea47f000 cdfs (deferred)
fffff80f`ea490000 fffff80f`ea49f000 dump_dumpata (deferred)
fffff80f`ea4b0000 fffff80f`ea4bd000 dump_atapi (deferred)
fffff80f`ea4c0000 fffff80f`ea4d2000 hidusb (deferred)
fffff80f`ea4e0000 fffff80f`ea51b000 HIDCLASS (deferred)
fffff80f`ea520000 fffff80f`ea533000 HIDPARSE (deferred)
fffff80f`ea540000 fffff80f`ea5c9000 mrxsmb (deferred)
fffff80f`ea5d0000 fffff80f`ea616000 mrxsmb20 (deferred)
fffff80f`ea620000 fffff80f`ea66f000 srvnet (deferred)
fffff80f`ea670000 fffff80f`ea735000 srv2 (deferred)
fffff80f`ea740000 fffff80f`ea76b000 winquic (deferred)
fffff80f`ea770000 fffff80f`ea8aa000 HTTP (deferred)
fffff80f`ea8b0000 fffff80f`ea986000 peauth (deferred)
fffff80f`ea990000 fffff80f`ea9a4000 tcpipreg (deferred)
fffff80f`ea9b0000 fffff80f`ea9cc000 rassstp (deferred)
fffff80f`ea9d0000 fffff80f`ea9e8000 NDProxy (deferred)
fffff80f`ea9f0000 fffff80f`eaa17000 AgileVpn (deferred)
fffff80f`eaa20000 fffff80f`eaa41000 rasl2tp (deferred)
fffff80f`eaa50000 fffff80f`eaa70000 raspptp (deferred)
fffff80f`eaa80000 fffff80f`eaa9c000 raspppoe (deferred)
fffff80f`eaaa0000 fffff80f`eaab5000 rasgre (deferred)
fffff80f`eaac0000 fffff80f`eaacf000 ndistapi (deferred)
fffff80f`eaad0000 fffff80f`eab0b000 ndiswan (deferred)
fffff80f`eab10000 fffff80f`eab23000 condrv (deferred)
fffff80f`eab30000 fffff80f`eab3f000 mouhid (deferred)
fffff80f`eab40000 fffff80f`eab56000 monitor (deferred)
fffff80f`eab60000 fffff80f`eac38000 dxgmms2 (deferred)
fffff80f`eac40000 fffff80f`eac69000 luafv (deferred)
fffff80f`eac70000 fffff80f`eac9d000 wcifs (deferred)
fffff80f`eaca0000 fffff80f`ead16000 cldflt (deferred)
fffff80f`ead20000 fffff80f`ead3b000 storqosflt (deferred)
fffff80f`ead40000 fffff80f`ead58000 lltdio (deferred)
fffff80f`ead60000 fffff80f`ead7a000 mslldp (deferred)
fffff80f`ead80000 fffff80f`ead9b000 rspndr (deferred)
fffff80f`eada0000 fffff80f`eadbc000 wanarp (deferred)
fffff80f`eadc0000 fffff80f`eade5000 bowser (deferred)
fffff80f`eae00000 fffff80f`eae7a000 VBoxSF (deferred)
fffff80f`eae80000 fffff80f`eaefa000 rdbss (deferred)
fffff80f`eaf00000 fffff80f`eaf12000 nsiproxy (deferred)
fffff80f`eaf20000 fffff80f`eaf2d000 npsvctrig (deferred)
fffff80f`eaf30000 fffff80f`eaf40000 mssmbios (deferred)
fffff80f`eaf50000 fffff80f`eaf7c000 dfsc (deferred)
fffff80f`eaf80000 fffff80f`eaf9a000 mpsdrv (deferred)
fffff80f`eafa0000 fffff80f`eafb4000 bam (deferred)
fffff80f`eafc0000 fffff80f`eafdb000 WdNisDrv (deferred)
I use windows server 2019 and the module should be ntoskrnl from the import in IDA. I didn't find the module in windbg somehow(maybe there is a alias).
That's the Windows' kernel binary, it's symbolic name is nt.
How do I know which module imports the function or the address of the function?
There are multiple ways of doing this, but I think the easiest is probably:
reload all modules symbolic information.
For this you can use the .reload command and especially the /f and /s switches. Be wary that it can take some time.
Side Note: When you list all modules (using lm) you can see that they are marked as being "deferred":
0: kd> lm
start end module name
ffffea92`71600000 ffffea92`718d3000 win32kbase (deferred)
ffffea92`718e0000 ffffea92`71c95000 win32kfull (deferred)
ffffea92`71ca0000 ffffea92`71ce9000 cdd (deferred)
ffffea92`72200000 ffffea92`7229a000 win32k (deferred)
fffff806`06200000 fffff806`06236000 wcifs (deferred)
fffff806`06240000 fffff806`06254000 mmcss (deferred)
fffff806`06260000 fffff806`062b6000 WUDFRd (deferred)
fffff806`062c0000 fffff806`06341000 cldflt (deferred)
...
This means the symbolic information is loaded only when needed ("lazy sombol loading"; e.g. when setting a breakpoint). If we want to find a symbol we really need that information to be loaded, thus we need .reload /f /s (or just .reload /f).
Search for the symbol.
Using the "examine symbol" command x. Notice you can use wildcards.
Example
Let say you have the NtCreateFile API and you want to know which module is implementing it:
0: kd> .reload /f
Loading Kernel Symbols
...............................................................
................................................................
......
0: kd> x *!NtCreateFile
fffff806`08e99260 nt!NtCreateFile (NtCreateFile)
0: kd> lmDvm nt
Browse full module list
start end module name
fffff806`08800000 fffff806`09846000 nt (pdb symbols) g:\symbols\ntkrnlmp.pdb\5D6312DA6921E3A4E7F938B88330B0771\ntkrnlmp.pdb
Loaded symbol image file: ntkrnlmp.exe
Image path: ntkrnlmp.exe
Image name: ntkrnlmp.exe
Browse all global symbols functions data
Image was built with /Brepro flag.
Timestamp: 73F1C0C4 (This is a reproducible build file hash, not a timestamp)
CheckSum: 00A65799
ImageSize: 01046000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Information from resource tables:
It's in the nt module (the kernel).
About .reload
Most of the time, you wont need to reload the symbols for the whole kernel space, since theoretically only the kernel binary (nt) provides the APIs that will be called. You should just do x and then if you don't have a proper answer then try to reload the other modules symbolic information with .reload /f.
Related
My colleagues and I are working with one of our PCIe-based products, and we've discovered that some kind of platform/chipset dependency is preventing interrupts from being delivered to our linux kernel driver (rapafp). One older version of the product that we have to continue to support in the field was sorta retrofit from an older PCI design. So what we've got is some FPGAs, one of which has a 66MHz PCI-32 interface, and that connects to a Texas Instruments XIO PCI-to-PCIe bridge. I should note that I've been researching this tirelessly for days, and I'm just not getting anywhere. We have definitely considered hardware problems with our own device, but we've swapped out multiple cards, and it doesn't make any difference.
Reference system that works
We have a system running RHEL6.5 that works great, so we're using that as a reference. Below is some info about the platform. I don't know what level of detail you will need, and I don't want to write a spammy question. Please let me know what else would be useful to provide and how (inline in the question, pastebin, etc.).
From uname -a:
Linux DL-2-107.localdomain 2.6.32-431.el6.i686 #1 SMP Fri Nov 22 00:26:36 UTC 2013 i686 i686 i386 GNU/Linux
From /proc/interrupts:
CPU0 CPU1
...
16: 609672457 1344098703 IO-APIC-fasteoi uhci_hcd:usb3, pata_jmicron, rapafp
Info from dmesg:
rapafp driver version 3.3.0.5
rapafp: Requesting IRQ 16
TSI: rapafp0 (BusID 2:0:0) is RAPTOR 4000 # 2048x2048
TSI: rapafp1 (BusID 2:0:0) is RAPTOR 4000 # 1280x1024
From lspci:
# lspci -t
-[0000:00]-+-00.0
+-01.0-[01-02]----00.0-[02]----00.0
00:01.0 PCI bridge: Intel Corporation 82Q35 Express PCI Express Root Port (rev 02) (prog-if 00 [Normal decode])
01:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200A PCI Express-to-PCI Bridge (rev 03) (prog-if 00 [Normal decode])
02:00.0 Display controller: Tech-Source Device 0042
CPU installed is:
model name : Intel(R) Core(TM)2 CPU E8400 # 3.00GHz
Some BIOS info from dmidecode:
Vendor: Phoenix Technologies, LTD
Version: 6.00 PG
Release Date: 12/12/2008
Note that the driver was never written with fasteoi in mind, so it never makes any end-of-interrupt calls. Nevertheless, it works flawlessly on that machine.
System that can't get any interrupts to our driver
We have two systems with problems receiving interrupts. One is running RHEL6.5 (2.6.32-431.el6.i686), and the other is RHEL7.4 (3.10.0-693.17.1.el7.x86_64).
The RHEL6 system is able to get interrupts to our driver, but only intermittently. This is likely due to the kernel connecting the device to an edge-triggered interrupt line (despite the driver requesting otherwise!) and the driver not being written to be compatible with edge-triggering.
The RHEL7 system isn't able to get interrupts to our driver at all. Our current objective is to port the driver to RHEL7, so I'll focus on that machine. The hosts share a lot of similarities with each other and differences from the reference system. The main differences that matter are kernel version, 32-bit vs. 64-bit, and possibly BIOS. To start with, below is some system info.
From uname -a:
Linux rhel74.techsource.com 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
/proc/interrupts:
10: 0 0 IO-APIC-edge rapafp
From dmesg:
[321790.744110] raptor_attach: irq_set_irq_type(10,8) succeeded!
[321790.744111] raptor_attach: calling request_irq.
[321790.744239] raptor_attach: request_irq(10) succeeded!
[321790.744240] raptor_attach: done
[321790.744342] TSI: rapafp0 (BusID 2:0:0) is RAPTOR 4000 # 2048x2048
...
[321807.840300] PCI Config Register dump:
[321807.840405] vendor id 0x1227
[321807.840508] device id 0x43
[321807.840611] command register 0x202
[321807.840715] status register 0x2a0
[321807.840818] revision id 0x0
[321807.840921] programming class code 0x0
[321807.841025] sub-class code 0x80
[321807.841129] basic class code 0x3
[321807.841232] header type 0x0
[321807.841335] base register 0 0xbfff0008
[321807.841439] base register 1 0xa0000008
[321807.841542] base register 2 0xb8000008
[321807.841645] base register 3 0x0
[321807.841749] base register 4 0xbffc0008
[321807.841852] base register 5 0x0
[321807.841955] Cardbus CIS Pointer 0x0
[321807.842059] Subsystem Vendor ID 0x1227
[321807.842162] Subsystem ID 0x43
[321807.842266] ROM base register 0x0
[321807.842369] interrupt line 0xa
[321807.842472] interrupt pin 0x1
[321807.842576] minimum grant 0x0
[321807.842679] maximum grant 0x0
Info from lspci:
# lspci -t
-[0000:00]-+-00.0
+-01.0-[01-02]----00.0-[02]----00.0
00:00.0 Host bridge: Intel Corporation 82X38/X48 Express DRAM Controller (rev 01)
Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device 3111
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
...
00:01.0 PCI bridge: Intel Corporation 82X38/X48 Express Host-Primary PCI Express Bridge (rev 01) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 24
...
01:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200A PCI Express-to-PCI Bridge (rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
...
02:00.0 Display controller: Tech-Source Device 0043
Subsystem: Tech-Source Device 0043
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B+ DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 10
Solutions attempted
There is a sequence of fixes I attempted. The first thing I did was go through the interrupt handling code and rewrite it so that it should be friendlier to an edge-triggered interrupt line, but that had no effect. Other things I did include:
There had been no call to pci_enable_device, so I added that. No effect.
I noticed that our call to request_irq was using legacy flags starting with SA_, so I replaced them with the newer ones starting with IRQF_. I tried all sorts of combinations of flags. IRQF_TRIGGER_RISING, IRQF_TRIGGER_FALLING, IRQF_TRIGGER_HIGH, IRQF_TRIGGER_LOW, combinations of those, with and without IRQF_SHARED, etc. None of these had any impact on IRQ delivery, what was reported by /proc/interrupts, or the bridge configurations reported by lspci. Nevertheless, request_irq never returned any error codes.
I tried calling enable_irq and set_irq_type. No matter what I passed to them, there was no effect. No error codes returned.
Eventually I noticed that the PCI bridge 00:01.0 had legacy interrupts (DisINTx+). I went hunting around for some kind of pre-existing function that would traverse the bridge hierarchy and fix up interrupts on all of them, but I couldn't find anything. So I decided to try experimenting.
First, I wrote my own function that would ascend the bridge hierarchy:
static int raptor_enable_intx(struct pci_dev *dev, TspciPtr pTspci) {
int num_en = 0;
int result;
u16 cmd, old_cmd;
while (dev) {
pci_read_config_word(dev, PCI_COMMAND, &old_cmd);
pci_intx(dev, true);
pci_read_config_word(dev, PCI_COMMAND, &cmd);
if (cmd & PCI_COMMAND_INTX_DISABLE) {
printk (KERN_INFO "raptor_enable_intx: Could not clear DisINTx for device %s\n", pci_name(dev));
} else {
printk (KERN_INFO "raptor_enable_intx: Successfully cleared DisINTx for device %s\n", pci_name(dev));
if ((old_cmd & PCI_COMMAND_INTX_DISABLE)) num_en++;
}
dev = pci_upstream_bridge(dev);
}
return num_en;
}
The main effect that this had was to cause the machine to hang, although not right away. I've tried calling request_irq before or after raptor_enable_intx. IIRC, one had no effect, while the other caused the system to hang, albeit not immediately.
I also found pci_common_swizzle with some comments about it being required by the PCI standard, so I call that after the above function. After I do those things, I then call request_irq. With these changes, the system hangs immediately on insmod.
Of course, I realize that iterating through the bridges and forcing PCI_COMMAND_INTX_DISABLE off is a disgusting hack, and I wouldn't be surprised if it's that or the swizzle that causes the system hang.
Anyhow, so I'm lost and baffled here. Does anyone know what I'm doing wrong? How am I supposed to get that system bridge to allow legacy interrupts to pass through?
Thanks in advance for the help!
I am trying kernel debugging using vmware and windbg.I have connected two OS and all symbols are loaded successfully.If I want to see my driver in memory how can I disassembly that?
I have tried lm commands and lmvm commands
kd> lmvm comint32
start end module name
88da9000 88daf000 comint32 (private pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\comint32.pdb\653387D894B4412FA9E30659E58DD47C1\comint32.pdb
Loaded symbol image file: comint32.sys
Image path: \SystemRoot\System32\Drivers\comint32.sys
Image name: comint32.sys
Timestamp: Thu Apr 11 20:10:55 2013 (51677B3F)
CheckSum: 0000CACF
ImageSize: 00006000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
x comint32!* should dump all the symbols of the module along with their addresses in memory.
You can then either use the u command (with the name (e.g. comint32!DriverEntry) or the address of a function as a parameter) to disassemble into the main window or you can open the disassembly window and paste the name/address into it and browse the disassembled code there.
See your windbg reference for further details.
I'm trying to dump heap information from full dump memory file sitting on Windows Server 2003 SP2 x86. Dump was created for 32-bit mixed (native/clr) application which was running on Windows Server 2003 SP2 x64 machine.
From the following windbg log I understand that loaded ntdll.dll image is incorrect and does not correspond to ntdll.pdb symbols. I have tried to specify the location to ntdll.dll from the target machine but windbg still shows that the module is loaded from the standard location (c:\windows\system32).
What did I do wrong? How to force windbg to load correct version of ntdll?
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.
[ ... skipped ... ]
0:042> vertarget
Windows Server 2003 Version 3790 (Service Pack 2) MP (4 procs) Free x86 compatible
Product: Server, suite: TerminalServer SingleUserTS
kernel32.dll version: 5.2.3790.4480 (srv03_sp2_gdr.090321-1244)
Machine Name:
Debug session time: Wed Mar 16 16:36:10.000 2011 (GMT-5)
System Uptime: 17 days 10:34:26.068
Process Uptime: 1 days 15:19:14.000
Kernel time: 0 days 1:24:01.000
User time: 0 days 22:07:58.000
0:042> .sympath
Symbol search path is: C:\mscordacwks\v2.0.50727.3615;C:\__exe;SRV*C\Symbols*http://referencesource.microsoft.com/symbols;SRV*c:\Symbols*http://msdl.microsoft.com/download/symbols;SRV*C:\Symbols*http://source.msdn.microsoft.com/symbols
0:042> .exepath
Executable image search path is: C:\__exe;C:\__target\Windows\SysWOW64;
0:042> .reload
[ ... skipped ... ]
0:042> .reload /u ntdll.dll
Unloaded ntdll.dll
0:042> .reload /v /f ntdll.dll
AddImage: C:\WINDOWS\system32\ntdll.dll // why is it still c:\windows\system32
DllBase = 7d600000
Size = 000f0000
Checksum = 000c371a
TimeDateStamp = 4cc1831e
0:042> lm
[ ... skipped ... ]
7d600000 7d6f0000 ntdll (pdb symbols) c:\symbols\wntdll.pdb\9ED8E09C6723448380648C4456726AEF2\wntdll.pdb
0:042> !heap
*************************************************************************
*** Your debugger is not using the correct symbols ***
[ ... skipped ... ]
*** Type referenced: ntdll!_HEAP_ENTRY ***
*************************************************************************
Invalid type information
0:042> lmi vm ntdll
start end module name
7d600000 7d6f0000 ntdll (pdb symbols) ntdll.dll
Symbol file: c:\symbols\wntdll.pdb\9ED8E09C6723448380648C4456726AEF2\wntdll.pdb
Image path: C:\WINDOWS\system32\ntdll.dll
Image name: ntdll.dll
Timestamp: Fri Oct 22 07:27:10 2010 (4CC1831E)
CheckSum: 000C371A
ImageSize: 000F0000
File version: 5.2.3790.4789 // this is correct and
Product version: 5.2.3790.4789 // does correspond to target computer
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: MicrosoftR WindowsR Operating System
InternalName: ntdll.dll
OriginalFilename: ntdll.dll
ProductVersion: 5.2.3790.4789
FileVersion: 5.2.3790.4789 (srv03_sp2_gdr.101019-0340)
FileDescription: NT Layer DLL
LegalCopyright: c Microsoft Corporation. All rights reserved.
UPDATE:
I moved a little bit further in my issue. I managed to connect to the live process on the customers side and tried to
investigate heap (heap -s) there and basically I got the same result.
(1520.7c4): Wake debugger - code 80000007 (first chance)
eax=00000000 ebx=00327d50 ecx=00000000 edx=00000000 esi=0030b428 edi=002debe4
eip=7d61c876 esp=002df008 ebp=002df06c iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\ntdll.dll -
ntdll!ZwReadFile+0x15:
7d61c876 c22400 ret 24h
0:000> !heap -s
*************************************************************************
*** Your debugger is not using the correct symbols ***
*** [...skipped...] ***
*** Type referenced: ntdll!_HEAP_ENTRY ***
*************************************************************************
Invalid type information
0:000> .reload
Reloading current modules
................................................................
....................................
0:000> !heap -s
*************************************************************************
*** Your debugger is not using the correct symbols ***
*** [...skipped...] ***
*** Type referenced: ntdll!_HEAP_ENTRY ***
*************************************************************************
Invalid type information
I think I have a problem similar to one mentioned in this article http://support.microsoft.com/kb/959207.
Environment and problem seem to be the same but dll versions are different, so it is not the solution for me.
I think I have to escalate this problem to Microsoft.
Does anybody know where I should go with this question?
This could happen if dump was created with 64 bit tools. There is good information on Tess's blog that explains the reason why bitness of the dump matters.
The solution appears to be easy but not obvious.
I found a wntdll.pdb slightly bigger than mine which contains required symbols and reloaded it with command .reload /f /i ntdll.dll
and I take the previous build of windbg 6.11.0001.404, in the current one 6.12.0002.633 !heap command still does not work in my case.
It looks like the type _HEAP_ENTRY is not included in the pdb of 2003 SP2 ntdll.dll
Microsoft released a hotfix http://support.microsoft.com/kb/959207, but you seem to have a later ntdll version.
Does anyone know whether the 'import address table' in the PE executable format on Windows is 'per dll' or 'per exe'?
Any PE can have an import address table, so both DLLs and EXEs can have them. This makes sense since both can have dependencies (imports) on other binaries. Unless you're doing dynamic loading (LoadLibrary/GetProcAddress), you'll have an import address table when calling into another module.
You can use the dumpbin utility with Visual Studio to see the imports of a PE:
An example on user32.dll:
C:\Windows\System32> dumpbin /imports
user32.dll
Microsoft (R) COFF/PE
Dumper Version 10.00.30319.01
Copyright (C) Microsoft Corporation.
All rights reserved.
Dump of file user32.dll
File Type: DLL
Section contains the following
imports:
ntdll.dll
7DC60000 Import Address Table
7DCCACEC Import Name Table
0 time date stamp
0 Index of first forwarder reference
15A NtOpenKey
7A9 wcscat_s
7AD wcscpy_s
...
...and for notepad.exe...
C:\Windows\System32> dumpbin /imports
notepad.exe
Microsoft (R) COFF/PE
Dumper Version 10.00.30319.01
Copyright (C) Microsoft Corporation.
All rights reserved.
Dump of file notepad.exe
File Type: EXECUTABLE IMAGE
Section contains the following
imports:
ADVAPI32.dll
1001000 Import Address Table
100A234 Import Name Table
FFFFFFFF time date stamp
FFFFFFFF Index of first forwarder reference
77C71C82 27E RegSetValueExW
77C7BCD5 26E RegQueryValueExW
77C7BED4 230 RegCloseKey
...
Short answer:
IAT(Import Address Table) is per PE file(dll and exe).
Long answer:
When the loader load exe file its copy each section of the PE to the process memory, unless IMAGE_SCN_MEM_DISCARDABLE is set for this sections. The IAT is in the .idata section (msdn):
The PE file's .idata section contains the information necessary for the loader to determine the addresses of the target functions and patch them into the executable image. The .idata section (or import table, as I prefer to call it) ...
IMAGE_SCN_MEM_DISCARDABLE is not set for idata section. Therefore- idata section copied to memory, and both exe and dll have this section- meaning IAT is per PE.
I wrote a simple dll loader here, if it help you understand.
I have a minidump crashed from a .NET application. Is there any way to know the CLR version (e.g. version of mscorwks.dll) of the fault machine (which generates the crash dump) using either Windbg or some other tool?
In WinDbg: the easiest way is to use the !eeversion command, but if you want additional info you can use the lm command with the v verbose option for the runtime module mscorwks. If you're on .NET 4 the runtime is called clr, so in that case you need to change the command accordingly.
0:026> lm vm mscorwks
start end module name
79e70000 7a3ff000 mscorwks T (no symbols)
Loaded symbol image file: mscorwks.dll
Image path: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Image name: mscorwks.dll
Timestamp: Wed Oct 24 09:41:29 2007 (471EF729)
CheckSum: 00597AA8
ImageSize: 0058F000
File version: 2.0.50727.1433
Product version: 2.0.50727.1433
File flags: 0 (Mask 3F)
File OS: 4 Unknown Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
!EEVersion should give the CLR version.
Go verbose in WinDbg:
>lm v
............. (lots of modules).......
687d0000 68d06000 System_Xml_ni (deferred)
Image path: C:\Windows\assembly\NativeImages_v2.0.50727_32\System.Xml\38b9d09539b67b08ee996db6c71f8a9b\System.Xml.ni.dll
Image name: System.Xml.ni.dll
Has CLR image header, track-debug-data flag not set
Timestamp: Mon Oct 06 20:43:49 2008 (48EADAF5)
CheckSum: 00000000
ImageSize: 00536000
File version: 2.0.50727.3074
Product version: 2.0.50727.3074
File flags: 0 (Mask 3F)
File OS: 4 Unknown Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft® .NET Framework
InternalName: System.Xml.dll
OriginalFilename: System.Xml.dll
ProductVersion: 2.0.50727.3074
FileVersion: 2.0.50727.3074 (QFE.050727-3000)
FileDescription: .NET Framework
LegalCopyright: © Microsoft Corporation. All rights reserved.
Comments: Flavor=Retail
Alternatively, load the dump in Visual Studio and use the Debug | Windows | Modules toolwindow to display some of this info.
Examples for two different .Net versions, using the version information of clr.dll:
.Net 4.0(.x?)
Image name: clr.dll
Timestamp: Thu Mar 18 21:39:07 2010 (4BA21EEB)
...
File version: 4.0.30319.1
Product version: 4.0.30319.1
.Net 4.5.2
Image name: clr.dll
Timestamp: Fri Nov 07 20:09:21 2014 (545CA861)
...
File version: 4.5.27.0
Product version: 4.0.30319.0