segfault in ld-linux-x86-64.so - linux

My manually built elf x64 file has started crashing on load, within the last three months or so.
It worked fine (and has done for about 10 years or so) on Ubuntu 20.04.x, but fails on 22.04 - same problem on Mint 19.3 and Fedora 36 and MX-linux MX21.
dmesg output:
[ 107.121214] p[4370]: segfault at 0 ip 00007f3d725b8350 sp 00007ffea111fba0 error 4
in ld-linux-x86-64.so.2[7f3d72598000+2a000]
[ 107.121230] Code: ff ff 00 45 31 db 48 8d 15 c9 ac 00 00 4c 8d 05 46 8f 01 00 4c 8d
2d 1f 8f 01 00 49 89 c2 48 8d 58 ff 48 89 f8 49 f7 da 66 90 <8b>
08 83 f9 07 77 19 85 c9 74 45 83 f9 07 77 40 48 63 0c 8a 48 01
You can download the offending file (a single plain 4MB ELF x64) from http://phix.x10.mx/p64 and I've included a detailed textual dump of all the headers below (but not the data or text sections).
It almost certainly contains older/rarer forms of relocations and suchlike, but
only ten of them and meant to be as simple as possible. One thing it does not have is all the messy got/plt stuff.
If I need to change the binary content of that file, I can, but might need a wee bit of help. (a "fake" got/plt maybe?)
Of course, if/once it gets through ld-linux-x86-64.so and complains about something else, ignore it, or should you be at all intrigued you can visit http://phix.x10.mx/download.php to get the full package.
References, just in case you need them, or to ask a wider set than just me for more details direct:
https://bugs.launchpad.net/ubuntu/+source/ld.so.preload-manager/+bug/1992468 (Oct 11th)
https://openeuphoria.org/forum/136972.wc?last_id=136973
https://github.com/petelomax/Phix/issues/13
The following is the first 1,276 bytes of the file from my own filedump program (the first 253 of 552,132 lines in total).
ELF Header
==========
00000000,ei_magic,x4,0x7F&&"ELF",ELF signature
00000004,ei_class,1,2,64 bit
00000005,ei_data,1,1,little endian
00000006,ei_version,1,1,current
00000007,ei_osabi,1,0,System V
00000008,ei_abiversion,1,0,
00000009,ei_pad,h6,000000000000h,
0000000F,ei_size,h1,00h,
00000010,e_type,2,2,Executable file
00000012,e_machine,2,62,x86-64
00000014,e_version,4,1,current
00000018,e_entry,h8, 674000h,
00000020,e_phoff,h8, 40h,program header table
00000028,e_shoff,h8, 0h,section header table
00000030,e_flags,h4,00000000h,
00000034,e_ehsize,h2,0040h,ELF header size
00000036,e_phentsize,2,56,program header table entry size
00000038,e_phnum,2,5,number of program header entries
0000003A,e_shentsize,2,64,section header entry size
0000003C,e_shnum,2,0,number of section header entries
0000003E,e_shstrndx,2,0,section name string table index
Program Headers
===============
00000040,p_type,4,3,PT_INTERP
00000044,p_flags,h4,00000004h,Read
00000048,p_offset,h8, 158h,file offset
00000050,p_vaddr,h8, 400158h,virtual address (see "Interpreter" tab)
00000058,p_paddr,h8, 400158h,physical addressing(ignored)
00000060,p_filesz,h8, 20h,bytes in file image
00000068,p_memsz,h8, 20h,bytes in memory image
00000070,p_align,h8, 1000h,
,-,,,
00000078,p_type,4,2,PT_DYNAMIC
0000007C,p_flags,h4,00000004h,Read
00000080,p_offset,h8, 178h,file offset
00000088,p_vaddr,h8, 400178h,virtual address (see "Dynamic Link Info" tab)
00000090,p_paddr,h8, 400178h,physical addressing(ignored)
00000098,p_filesz,h8, B0h,bytes in file image
000000A0,p_memsz,h8, B0h,bytes in memory image
000000A8,p_align,h8, 1000h,
,-,,,
000000B0,p_type,4,1,PT_LOAD
000000B4,p_flags,h4,00000006h,Read+Write
000000B8,p_offset,h8, 228h,file offset
000000C0,p_vaddr,h8, 400228h,virtual address (see "Symtab" tab)
000000C8,p_paddr,h8, 400228h,physical addressing(ignored)
000000D0,p_filesz,h8, 2D8h,bytes in file image
000000D8,p_memsz,h8, 2D8h,bytes in memory image
000000E0,p_align,h8, 1000h,
,-,,,
000000E8,p_type,4,1,PT_LOAD
000000EC,p_flags,h4,00000006h,Read+Write
000000F0,p_offset,h8, 500h,file offset
000000F8,p_vaddr,h8, 400500h,virtual address (see "Data Segment" tab)
00000100,p_paddr,h8, 400500h,physical addressing(ignored)
00000108,p_filesz,h8, 273B00h,bytes in file image
00000110,p_memsz,h8, 273B00h,bytes in memory image
00000118,p_align,h8, 1000h,
,-,,,
00000120,p_type,4,1,PT_LOAD
00000124,p_flags,h4,00000005h,Read+Execute
00000128,p_offset,h8, 274000h,file offset
00000130,p_vaddr,h8, 674000h,virtual address (see "Code Segment" tab)
00000138,p_paddr,h8, 674000h,physical addressing(ignored)
00000140,p_filesz,h8, 1C1734h,bytes in file image
00000148,p_memsz,h8, 1C1734h,bytes in memory image
00000150,p_align,h8, 1000h,
,-,,,
Interpreter
===========
00000158,00400158,-,2F6C6962 36342F6C ,/lib64/l
00000160,00400160,-,642D6C69 6E75782D 7838362D 36342E73 ,d-linux-x86-64.s
00000170,00400170,-,6F2E3200 00000000 ,o.2.....
Dynamic Link Info
=================
00000178,d_tag,h8, 1h,DT_NEEDED
00000180,d_val,8,1,libc.so.6
00000188,d_tag,h8, 1h,DT_NEEDED
00000190,d_val,8,62,libdl.so.2
00000198,d_tag,h8, 6h,DT_SYMTAB
000001A0,d_ptr,h8, 400228h,(See "Symtab" tab)
000001A8,d_tag,h8, Bh,DT_SYMENT
000001B0,d_val,8,16, (- size of one symtab entry)
000001B8,d_tag,h8, 4h,DT_HASH
000001C0,d_ptr,h8, 400330h,(See "Symtab" tab, Hash)
000001C8,d_tag,h8, 5h,DT_STRTAB
000001D0,d_ptr,h8, 400368h,(See "Symtab" tab, Strings)
000001D8,d_tag,h8, Ah,DT_STRSZ
000001E0,d_val,8,88, (- strings end at #000003BF)
000001E8,d_tag,h8, 7h,DT_RELA
000001F0,d_ptr,h8, 4003C0h,(See "Symtab" tab, Relocationas)
000001F8,d_tag,h8, 8h,DT_RELASZ
00000200,d_val,8,240, (- total DT_RELA table size)
00000208,d_tag,h8, 9h,DT_RELAENT
00000210,d_val,8,24, (- size of one DT_RELA entry)
00000218,d_tag,h8, 0h,DT_NULL
00000220,d_tag,h8, 0h,DT_NULL
Symtab
======
,--Symtab--,,,
00000228,st_name[0],h4,00000000h,DT_SYMTAB [#00400228]
0000022C,st_info,h1,00h,
0000022D,st_other,h1,00h,(should be 0)
0000022E,st_shndx,h2,0000h,
00000230,st_value,h8, 0h,
00000238,st_size,8,0,
,-,,,
00000240,st_name[1],h4,0000000Bh,mmap
00000244,st_info,h1,12h,STB_GLOBAL, STT_FUNC
00000245,st_other,h1,00h,(should be 0)
00000246,st_shndx,h2,0000h,
00000248,st_value,h8, 0h,
00000250,st_size,8,0,
,-,,,
00000258,st_name[2],h4,00000010h,getenv
0000025C,st_info,h1,12h,STB_GLOBAL, STT_FUNC
0000025D,st_other,h1,00h,(should be 0)
0000025E,st_shndx,h2,0000h,
00000260,st_value,h8, 0h,
00000268,st_size,8,0,
,-,,,
00000270,st_name[3],h4,00000017h,unsetenv
00000274,st_info,h1,12h,STB_GLOBAL, STT_FUNC
00000275,st_other,h1,00h,(should be 0)
00000276,st_shndx,h2,0000h,
00000278,st_value,h8, 0h,
00000280,st_size,8,0,
,-,,,
00000288,st_name[4],h4,00000020h,setenv
0000028C,st_info,h1,12h,STB_GLOBAL, STT_FUNC
0000028D,st_other,h1,00h,(should be 0)
0000028E,st_shndx,h2,0000h,
00000290,st_value,h8, 0h,
00000298,st_size,8,0,
,-,,,
000002A0,st_name[5],h4,00000027h,close
000002A4,st_info,h1,12h,STB_GLOBAL, STT_FUNC
000002A5,st_other,h1,00h,(should be 0)
000002A6,st_shndx,h2,0000h,
000002A8,st_value,h8, 0h,
000002B0,st_size,8,0,
,-,,,
000002B8,st_name[6],h4,0000002Dh,dup2
000002BC,st_info,h1,12h,STB_GLOBAL, STT_FUNC
000002BD,st_other,h1,00h,(should be 0)
000002BE,st_shndx,h2,0000h,
000002C0,st_value,h8, 0h,
000002C8,st_size,8,0,
,-,,,
000002D0,st_name[7],h4,00000032h,fork
000002D4,st_info,h1,12h,STB_GLOBAL, STT_FUNC
000002D5,st_other,h1,00h,(should be 0)
000002D6,st_shndx,h2,0000h,
000002D8,st_value,h8, 0h,
000002E0,st_size,8,0,
,-,,,
000002E8,st_name[8],h4,00000037h,system
000002EC,st_info,h1,12h,STB_GLOBAL, STT_FUNC
000002ED,st_other,h1,00h,(should be 0)
000002EE,st_shndx,h2,0000h,
000002F0,st_value,h8, 0h,
000002F8,st_size,8,0,
,-,,,
00000300,st_name[9],h4,00000049h,dlopen
00000304,st_info,h1,12h,STB_GLOBAL, STT_FUNC
00000305,st_other,h1,00h,(should be 0)
00000306,st_shndx,h2,0000h,
00000308,st_value,h8, 0h,
00000310,st_size,8,0,
,-,,,
00000318,st_name[10],h4,00000050h,dlsym
0000031C,st_info,h1,12h,STB_GLOBAL, STT_FUNC
0000031D,st_other,h1,00h,(should be 0)
0000031E,st_shndx,h2,0000h,
00000320,st_value,h8, 0h,
00000328,st_size,8,0,
,-,,,
,--Hash--,,,
00000330,nbucket,4,1,DT_HASH [#00400330]
00000334,nchain,4,11,(also defines DT_SYMTAB size)
00000338,bucket[0],4,0,
0000033C,chain[0],4,1,
00000340,chain[1],4,2,
00000344,chain[2],4,3,
00000348,chain[3],4,4,
0000034C,chain[4],4,5,
00000350,chain[5],4,6,
00000354,chain[6],4,7,
00000358,chain[7],4,8,
0000035C,chain[8],4,9,
00000360,chain[9],4,10,
00000364,chain[10],4,0,
,-,,,
,--Strings--,,,
00000368,00000000,-,00,.
00000369,00000001,-,6C6962632E736F2E3600,libc.so.6.
00000373,0000000B,-,6D6D617000,mmap.
00000378,00000010,-,676574656E7600,getenv.
0000037F,00000017,-,756E736574656E7600,unsetenv.
00000388,00000020,-,736574656E7600,setenv.
0000038F,00000027,-,636C6F736500,close.
00000395,0000002D,-,6475703200,dup2.
0000039A,00000032,-,666F726B00,fork.
0000039F,00000037,-,73797374656D00,system.
000003A6,0000003E,-,6C6962646C2E736F2E3200,libdl.so.2.
000003B1,00000049,-,646C6F70656E00,dlopen.
000003B8,00000050,-,646C73796D000000,dlsym...
,-,,,
,--Relocationas--,,,
000003C0,r_offset,h8, 4004B0h,DT_RELA [#004003C0]
000003C8,r_info,h8, 100000001h,R_X86_64_64, symtab[1]=mmap
000003D0,r_addend,h8, 0h,
000003D8,r_offset,h8, 4004B8h,
000003E0,r_info,h8, 200000001h,R_X86_64_64, symtab[2]=getenv
000003E8,r_addend,h8, 0h,
000003F0,r_offset,h8, 4004C0h,
000003F8,r_info,h8, 300000001h,R_X86_64_64, symtab[3]=unsetenv
00000400,r_addend,h8, 0h,
00000408,r_offset,h8, 4004C8h,
00000410,r_info,h8, 400000001h,R_X86_64_64, symtab[4]=setenv
00000418,r_addend,h8, 0h,
00000420,r_offset,h8, 4004D0h,
00000428,r_info,h8, 500000001h,R_X86_64_64, symtab[5]=close
00000430,r_addend,h8, 0h,
00000438,r_offset,h8, 4004D8h,
00000440,r_info,h8, 600000001h,R_X86_64_64, symtab[6]=dup2
00000448,r_addend,h8, 0h,
00000450,r_offset,h8, 4004E0h,
00000458,r_info,h8, 700000001h,R_X86_64_64, symtab[7]=fork
00000460,r_addend,h8, 0h,
00000468,r_offset,h8, 4004E8h,
00000470,r_info,h8, 800000001h,R_X86_64_64, symtab[8]=system
00000478,r_addend,h8, 0h,
00000480,r_offset,h8, 4004F0h,
00000488,r_info,h8, 900000001h,R_X86_64_64, symtab[9]=dlopen
00000490,r_addend,h8, 0h,
00000498,r_offset,h8, 4004F8h,
000004A0,r_info,h8, A00000001h,R_X86_64_64, symtab[10]=dlsym
000004A8,r_addend,h8, 0h,
,-,,,
,--relocs--,,,
000004B0,reloc[1] (#004004B0),-,00000000 00000000 ,........
000004B8,reloc[2] (#004004B8),-,00000000 00000000 ,........
000004C0,reloc[3] (#004004C0),-,00000000 00000000 ,........
000004C8,reloc[4] (#004004C8),-,00000000 00000000 ,........
000004D0,reloc[5] (#004004D0),-,00000000 00000000 ,........
000004D8,reloc[6] (#004004D8),-,00000000 00000000 ,........
000004E0,reloc[7] (#004004E0),-,00000000 00000000 ,........
000004E8,reloc[8] (#004004E8),-,00000000 00000000 ,........
000004F0,reloc[9] (#004004F0),-,00000000 00000000 ,........
000004F8,reloc[10] (#004004F8),-,00000000 00000000 ,........
Update (after four months of getting nowhere): on a new mint 21 cinnamon 64bit vm:
pete#pete-VirtualBox:~/phix$ ./p64
Segmentation fault (core dumped)
pete#pete-VirtualBox:~/phix$ /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 ./p64
Phix hybrid interpreter/compiler.
Version 1.0.2 (64 bit Linux) Copyright Pete Lomax 2006..2022
Enter ? for options or filename to execute:-test
which completes fine...
Though not entirely surprisingly, "-c -test" segfaults on the first one...

Finally got it. It seems simply that p_align is now more strictly applied (fair enough, I guess).

Related

Read errors after an UBIFS update

I am encountering the messages below after creating an UBIFS filesystem in
a new UBI volume on an existing UBI partition.
This happens while reading all the files on the UBI fs via tar -cf /dev/null *:
UBIFS error (pid 1810): ubifs_read_node: bad node type (255 but expected 1)
UBIFS error (pid 1810): ubifs_read_node: bad node at LEB 33:967120, LEB mapping status 0
Not a node, first 24 bytes:
00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
CPU: 0 PID: 1810 Comm: tar Tainted: P O 3.18.80 #3
Backtrace:
[<8001b664>] (dump_backtrace) from [<8001b880>] (show_stack+0x18/0x1c)
r7:00000000 r6:00000000 r5:80000013 r4:80566cbc
[<8001b868>] (show_stack) from [<801d77e0>] (dump_stack+0x88/0xa4)
[<801d7758>] (dump_stack) from [<80171608>] (ubifs_read_node+0x1fc/0x2b8)
r7:00000021 r6:00000712 r5:000ec1d0 r4:bd59d000
[<8017140c>] (ubifs_read_node) from [<8018b654>](ubifs_tnc_read_node+0x88/0x124)
r10:00000000 r9:b4f9fdb0 r8:bd59d264 r7:00000001 r6:b71e6000 r5:bd59d000
r4:b6126148
[<8018b5cc>] (ubifs_tnc_read_node) from [<80174690>](ubifs_tnc_locate+0x108/0x1e0)
r7:00000001 r6:b71e6000 r5:00000001 r4:bd59d000
[<80174588>] (ubifs_tnc_locate) from [<80168200>] (do_readpage+0x1c0/0x39c)
r10:bd59d000 r9:000005b1 r8:00000000 r7:bd258710 r6:a5914000 r5:b71e6000
r4:be09e280
[<80168040>] (do_readpage) from [<80169398>] (ubifs_readpage+0x44/0x424)
r10:00000000 r9:00000000 r8:bd59d000 r7:be09e280 r6:00000000 r5:bd258710
r4:00000000
[<80169354>] (ubifs_readpage) from [<80089654>](generic_file_read_iter+0x48c/0x5d8)
r10:00000000 r9:00000000 r8:00000000 r7:be09e280 r6:bd2587d4 r5:bd5379e0
r4:00000000
[<800891c8>] (generic_file_read_iter) from [<800bbd60>](new_sync_read+0x84/0xa8)
r10:00000000 r9:b4f9e000 r8:80008e24 r7:bd6437a0 r6:bd5379e0 r5:b4f9ff80
r4:00001000
[<800bbcdc>] (new_sync_read) from [<800bc85c>] (__vfs_read+0x20/0x54)
r7:b4f9ff80 r6:7ec2d800 r5:00001000 r4:800bbcdc
[<800bc83c>] (__vfs_read) from [<800bc91c>] (vfs_read+0x8c/0xf4)
r5:00001000 r4:bd5379e0
[<800bc890>] (vfs_read) from [<800bc9cc>] (SyS_read+0x48/0x80)
r9:b4f9e000 r8:80008e24 r7:00001000 r6:7ec2d800 r5:bd5379e0 r4:bd5379e0
[<800bc984>] (SyS_read) from [<80008c80>] (ret_fast_syscall+0x0/0x3c)
r7:00000003 r6:7ec2d800 r5:00000008 r4:00082a08
UBIFS error (pid 1811): do_readpage: cannot read page 0 of inode 1457, error -22
Mounting looks like this:
UBI-0: ubi_attach_mtd_dev:default fastmap pool size: 190
UBI-0: ubi_attach_mtd_dev:default fastmap WL pool size: 25
UBI-0: ubi_attach_mtd_dev:attaching mtd3 to ubi0
UBI-0: scan_all:scanning is finished
UBI-0: ubi_attach_mtd_dev:attached mtd3 (name "data", size 3824 MiB)
UBI-0: ubi_attach_mtd_dev:PEB size: 1048576 bytes (1024 KiB), LEB size: 1040384 bytes
UBI-0: ubi_attach_mtd_dev:min./max. I/O unit sizes: 4096/4096, sub-page size 4096
UBI-0: ubi_attach_mtd_dev:VID header offset: 4096 (aligned 4096), data offset: 8192
UBI-0: ubi_attach_mtd_dev:good PEBs: 3816, bad PEBs: 8, corrupted PEBs: 0
UBI-0: ubi_attach_mtd_dev:user volume: 6, internal volumes: 1, max. volumes count: 128
UBI-0: ubi_attach_mtd_dev:max/mean erase counter: 4/2, WL threshold: 4096, image sequence number: 1362948729
UBI-0: ubi_attach_mtd_dev:available PEBs: 2313, total reserved PEBs: 1503, PEBs reserved for bad PEB handling: 72
UBI-0: ubi_thread:background thread "ubi_bgt0d" started, PID 419
UBIFS: mounted UBI device 0, volume 6, name "slot1", R/O mode
UBIFS: LEB size: 1040384 bytes (1016 KiB), min./max. I/O unit sizes: 4096 bytes/4096 bytes
UBIFS: FS size: 259055616 bytes (247 MiB, 249 LEBs), journal size 12484608 bytes (11 MiB, 12 LEBs)
UBIFS: reserved for root: 4952683 bytes (4836 KiB)
UBIFS: media format: w4/r0 (latest is w4/r0), UUID 92C7B251-2666-4717-B735-5539900FE749, small LPT model
The rate of reproduction is one in about 20 sequences of: ubirmvol,
ubimkvol (256MB), unpack a rootfs.tgz (20MB, 40MB unpacked) in the
mounted UBIFS, umount, ubidetach, sync, reboot. There are no xattrs
created. No power cuts happen during the tests.
The board runs a 3.18.80 kernel on an ARM board. I tested other
identical test boards where only the NAND chip manufacturer was
different.
I had CONFIG_MTD_UBI_FASTMAP enabled when the error occured, but I
used no explicit fastmap boot cmdline option. I tried mounting the
ubifs with a rebuilt kernel that had the config option disabled after
the issue reproduced, but the read error still occured.
I also tried mounting with a kernel that had "ubifs: Fix journal
replay w.r.t. xattr nodes" patch [1] applied, after reading older similar error reports, but once reproduced on a NAND, the read error
persisted.
[1] https://patchwork.ozlabs.org/patch/713213/
Is there some special requirement except just umount, ubidetach and
sync before running reboot, or regarding free space fixup ? Would
creating the fs image offline with mkfs.ubifs instead of unpacking it
via tar make a difference here ? Would it help to test with
cherry picked commits from linux v4.14 that touch
fs/ubifs ?

Not able to collect Crash Dump on FreeBSD 11.0

I have to debug a crash. But everytime my system crash it failed to dump the crashdump into the swap memory. The erorr i am seeing is:-
**Uptime: 7m32s
Dumping 3735 out of 131037 MB:..1%(ada0:ahcich0:0:0:0): WRITE_DMA48. ACB: 35 00 16 c9 c3 40 39 00 00 00 08 00
(ada0:ahcich0:0:0:0): CAM status: CCB request was invalid
(ada0:ahcich0:0:0:0): Error 22, Unretryable error
Aborting dump due to I/O error.
** DUMP FAILED (ERROR 22) **
**
In my rc.conf i have set the dumpdev to AUTO and my swap memory is 4GB.
Here is the ouput of fstab:-
# Device Mountpoint FStype Options Dump Pass#
/dev/ada0p2 / ufs rw 1 1
/dev/ada0p3 none swap sw 0 0
Thanks
Your swap partition is smaller than your memory.
How do you expect 12 Gig to fit into 4Gig?

Mac Yosemite: Remove all space characters on lines that are starting with 0 (zero), in a standard text file

I have a text files, which is text copied from a subtitle file, that looks like this:
1
00 : 00 : 02 , 240 --> 00 : 00 : 04 , 240
(tadashi) <watashi no namae wa kanzaki jika.
2
00 : 00 : 04 , 240 --> 00 : 00 : 06 , 240
makikomare te shimatta watashi wa
tsuini?
...
it goes on for some ~300 more chunks like this.
How would I make it look like this, without doing it manually :) :
1
00:00:02,240 --> 00:00:04,240
(tadashi) <watashi no namae wa kanzaki jika.
2
00:00:04,240 --> 00:00:06,240
makikomare te shimatta watashi wa
tsuini?
...
Basically, I would like to remove all spaces on lines that are starting with the number zero, except those spaces that are before and after the "arrow"
I am on OSX Yosemite but, if the only solution would be on some other os, I'd be glad to hear it regardless
Since no one has answered you yet, here is a solution in python. You need to replace source and target filenames with what is appropriate for you.
#!/usr/bin/python
import re # this is the regex library
f = open('source.txt', 'rt') # this is the name of your source file
fnew = open('target.txt', 'wt') # this is the name of your target file
for line in f:
new = re.sub(r'(\d\d) ([:|,]) (\d\d)', "\\1\\2\\3", line)
fnew.write(new)
f.close()
fnew.close()

How to Find the context record for user mode exception on X64

I have a user mode dump from Win 8.1/64, the dump was taken by attaching Windbg when the Wer dialogue. The .ecxr shows then ntdll!DbgBreakPoint for the Windbg injected thread. (As normal)
I have identified the thread by examine all stack, and finding the one which has :
# Call Site
00 ntdll!NtWaitForMultipleObjects
01 KERNELBASE!WaitForMultipleObjectsEx
02 kernel32!WerpReportFaultInternal
03 kernel32!WerpReportFault
04 KERNELBASE!UnhandledExceptionFilter
05 ntdll!RtlUserThreadStart$filt$0
06 ntdll!_C_specific_handler
07 ntdll!RtlpExecuteHandlerForException
08 ntdll!RtlDispatchException
09 ntdll!KiUserExceptionDispatch
10 <My faulty code which generated the exception>
The kvn aslo dispays a TrapFrame # 00000000`0379ed28)
09 00000000`0379e900 00000000`00250bc8 : 00000000`00000000 00000000`0026ca09 00000000`0379f160 00000000`0379f168 : ntdll!KiUserExceptionDispatch+0x2e (TrapFrame # 00000000`0379ed28)
Is there a way to use the trap frame to get the context record to feed into .cxr ?
Or is it other possibilities to find the exception context?
I see a KERNELBASE!UnhandledExceptionFilter on the stack. That seems like a good thing to focus on.
If this were x86, you could easily get an EXCEPTION_POINTERS struct out of the first parameter to KERNELBASE!UnhandledExceptionFilter. From there, you would have access to the EXCEPTION_RECORD and CONTEXT. The procedure is described in this KB article.
The same method works for x64 processes with one caveat. Due to the nature of the x64 calling convention, it is harder to retrieve the actual argument to KERNELBASE!UnhandledExceptionFilter since it is stored in a register rather than on the stack.
I recently found a debugger extension called CMKD that automates the task of hunting for the first 4 args in the x64 calling convention rather than blindly displaying stack values like kb and kv. This can be done by hand but it is a rather lengthy and error-prone process -- better to let an extension take a crack at it first.
With it, you can do something like this:
0:000> !cmkd.stack -p
Call Stack : 15 frames
## Stack-Pointer Return-Address Call-Site
[...]
03 000000aea3dae7e0 00007fff1e906b14 KERNELBASE!UnhandledExceptionFilter+196
Parameter[0] = 000000aea3dae930
Parameter[1] = (unknown)
Parameter[2] = (unknown)
Parameter[3] = (unknown)
[...]
And, now we have an EXCEPTION_POINTERS* in Parameter[0].
0:000> dt 000000ae`a3dae930 EXCEPTION_POINTERS
ConsoleApplication2!EXCEPTION_POINTERS
+0x000 ExceptionRecord : 0x000000ae`a3daf850 _EXCEPTION_RECORD
+0x008 ContextRecord : 0x000000ae`a3daf240 _CONTEXT
We can see in my example that a C++ exception was thrown...
0:000> .exr 000000ae`a3daf850
ExceptionAddress: 00007fff1bfeab78 (KERNELBASE!RaiseException+0x0000000000000068)
ExceptionCode: e06d7363 (C++ EH exception)
ExceptionFlags: 00000001
NumberParameters: 4
Parameter[0]: 0000000019930520
Parameter[1]: 000000aea3daf9b0
Parameter[2]: 00007ff6f50024a8
Parameter[3]: 00007ff6f5000000
pExceptionObject: 000000aea3daf9b0
_s_ThrowInfo : 00007ff6f50024a8
Hopefully this helps. Good luck. :)
Another method fox x64 case doesn't require extension but is relying on two unstable facts:
windbg ability to reconstruct registers for a specific frame
the fact that WerpReportFault stores EXCEPTION_POINTERS address in rdi before passing it to WerpReportFaultInternal (it is the case at least for kernel32.dll 6.1.7601.23915 (win7sp1_ldr.170913-0600)
Exception pointer can be extracted as an rdi value of the WerpReportFault's frame:
0:007> k
# Child-SP RetAddr Call Site
00 00000000`0868dcd8 000007fe`fcf61430 ntdll!NtWaitForMultipleObjects+0xa
01 00000000`0868dce0 00000000`76fb16e3 KERNELBASE!WaitForMultipleObjectsEx+0xe8
02 00000000`0868dde0 00000000`7702b8b5 kernel32!WaitForMultipleObjectsExImplementation+0xb3
03 00000000`0868de70 00000000`7702ba37 kernel32!WerpReportFaultInternal+0x215
04 00000000`0868df10 00000000`7702ba8f kernel32!WerpReportFault+0x77
05 00000000`0868df40 00000000`7702bcac kernel32!BasepReportFault+0x1f
06 00000000`0868df70 00000000`77230108 kernel32!UnhandledExceptionFilter+0x1fc
07 00000000`0868e050 00000000`771c7958 ntdll! ?? ::FNODOBFM::`string'+0x2025
08 00000000`0868e080 00000000`771d812d ntdll!_C_specific_handler+0x8c
09 00000000`0868e0f0 00000000`771c855f ntdll!RtlpExecuteHandlerForException+0xd
0a 00000000`0868e120 00000000`771fbcb8 ntdll!RtlDispatchException+0x45a
0b 00000000`0868e800 000007fe`fe03df54 ntdll!KiUserExceptionDispatch+0x2e
0c 00000000`0868ef00 000007fe`fe03e1b6 gdi32!pmfAllocMF+0x2b0
0d 00000000`0868ef70 000007fe`fb10a646 gdi32!GetEnhMetaFileW+0x32
0e 00000000`0868efb0 000007fe`fb0c4959 GdiPlus!GpMetafile::GpMetafile+0x1c6
0f 00000000`0868f150 00000001`40001c35 GdiPlus!GdipCreateBitmapFromFile+0xc5
0:007> .frame /r 04
04 00000000`0868df10 00000000`7702ba8f kernel32!WerpReportFault+0x77
rax=00000000c0000001 rbx=0000000000000000 rcx=0000000002660000
rdx=0000000000000001 rsi=0000000000000001 rdi=000000000868e0b0
rip=000000007702ba37 rsp=000000000868df10 rbp=000000000868ff90
r8=000000000868d3f8 r9=000000000868d560 r10=0000000000000000
r11=0000000000000246 r12=000000000868e0b0 r13=0000000000000000
r14=0000000000000002 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000244
kernel32!WerpReportFault+0x77:
00000000`7702ba37 8b0d27ff0600 mov ecx,dword ptr [kernel32!RestrictedUserHandle+0xc (00000000`7709b964)] ds:00000000`7709b964=00000000
0:007> .exptr 000000000868e0b0
----- Exception record at 00000000`0868ecf0:
ExceptionAddress: 000007fefe03df54 (gdi32!pmfAllocMF+0x00000000000002b0)
ExceptionCode: c0000006 (In-page I/O error)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 0000000000000000
Parameter[1]: 0000000002610028
Parameter[2]: 00000000c00000be
Inpage operation failed at 0000000002610028, due to I/O error 00000000c00000be
----- Context record at 00000000`0868e800:
rax=0000000002610000 rbx=000000000e5fe7c0 rcx=0000000000006894
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=000007fefe03df54 rsp=000000000868ef00 rbp=0000000000000104
r8=000000000868ee38 r9=0000000000000104 r10=0000000000000000
r11=0000000000000286 r12=0000000000000001 r13=000000006d9cf760
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206
gdi32!pmfAllocMF+0x2b0:
000007fe`fe03df54 81782820454d46 cmp dword ptr [rax+28h],464D4520h ds:00000000`02610028=????????
I did some research and found two ways of getting it without any plugins, relying on WinDBG magic, etc.
First, invoke k command in WinDBG. Find a portion of stack like this:
Child-SP RetAddr
00000000`0ab7d9d0 00007ff9`98baed2d exception handler
00000000`0ab7da10 00007ff9`98b16c86 ntdll!RtlpExecuteHandlerForException+0xd
00000000`0ab7da40 00007ff9`98badc5e ntdll!RtlDispatchException+0x3c6
00000000`0ab7e140 00007ff9`98b5b48a ntdll!KiUserExceptionDispatch+0x2e
00000000`0ab7e860 00007ff9`96925531 Function that crashed
Now you can find what you want in local variables:
Option 1: Use EXCEPTION_POINTERS structure saved on stack
.exptr 00000000`0ab7da10 - 0x20
Option 2: Use CONTEXT and EXCEPTION_RECORD separately
.cxr 00000000`0ab7e140
.exr 00000000`0ab7e140 + ##c++(sizeof(ntdll!_CONTEXT)) + 0x20

DLL issues after upgrading from VS2008 to VS2010

I'm dealing with this issue: We have recently upgraded to VS2010 and I am working on recompiling all of our software tools in '10. One of these tools in VC++ was created by an outside vendor. We have the source code for this tool (fairly old) and its required dll (also fairly old), although we don't have the source for the dll. The problem arises when I build the project and get several unresolved externals (LNK2019). I've used a dll export viewer and verified that the dll is in fact exporting the right functions, and I've experimented with a few other workarounds to no avail. The only explanation I can come up with is that the dll, likely built in VS2005, also needs to be rebuilt in VS2010 - although my experience (which I admit is limited) tells me that this should not be necessary.
My question is: Is this really an issue? Does a dll built in an older version of VS need to be rebuilt in the version that the project that uses it is currently using?
I can provide more details if necessary.
Thank you,
Andy
Dump of file usbcan32.dll
File Type: DLL
Section contains the following imports:
SETUPAPI.dll
10012188 Import Address Table
10016E8C Import Name Table
0 time date stamp
0 Index of first forwarder reference
12D SetupDiGetClassDevsA
11F SetupDiEnumDeviceInterfaces
143 SetupDiGetDeviceInterfaceDetailA
VERSION.dll
100121D4 Import Address Table
10016ED8 Import Name Table
0 time date stamp
0 Index of first forwarder reference
0 GetFileVersionInfoA
A VerQueryValueA
1 GetFileVersionInfoSizeA
KERNEL32.dll
10012020 Import Address Table
10016D24 Import Name Table
0 time date stamp
0 Index of first forwarder reference
347 Sleep
169 GetLastError
21E InterlockedDecrement
247 LeaveCriticalSection
8F EnterCriticalSection
309 SetEvent
383 WaitForSingleObject
49 CreateEventA
1F5 GlobalFree
200 GlobalUnlock
1F9 GlobalLock
1EE GlobalAlloc
1E9 GetWindowsDirectoryA
219 InitializeCriticalSection
7A DeleteCriticalSection
2E CloseHandle
24 CancelIo
2B6 ReleaseMutex
381 WaitForMultipleObjects
271 OpenEventA
278 OpenMutexA
5A CreateMutexA
7C DeleteFileA
1DF GetVersionExA
1BE GetSystemTime
175 GetModuleFileNameA
177 GetModuleHandleA
378 VirtualLock
373 VirtualAlloc
18B GetOEMCP
376 VirtualFree
2C5 ResumeThread
222 InterlockedIncrement
25E MapViewOfFile
4E CreateFileMappingA
13B GetCurrentProcessId
363 UnmapViewOfFile
83 DeviceIoControl
252 LocalFree
EA FormatMessageA
4D CreateFileA
2A9 ReadFile
394 WriteFile
18C GetOverlappedResult
336 SetThreadPriority
69 CreateThread
F5 GetACP
32A SetStdHandle
FC GetCPInfo
16C GetLocaleInfoA
21F InterlockedExchange
2CA RtlUnwind
1B1 GetStdHandle
248 LoadLibraryA
360 UnhandledExceptionFilter
14F GetEnvironmentStringsW
EE FreeEnvironmentStringsW
14D GetEnvironmentStrings
ED FreeEnvironmentStringsA
212 HeapSize
303 SetEndOfFile
1B2 GetStringTypeA
15E GetFileType
1AF GetStartupInfoA
20A HeapDestroy
1D5 GetTickCount
1B5 GetStringTypeW
210 HeapReAlloc
AF ExitProcess
20C HeapFree
206 HeapAlloc
108 GetCommandLineA
297 QueryPerformanceCounter
13E GetCurrentThreadId
1C0 GetSystemTimeAsFileTime
379 VirtualProtect
1BB GetSystemInfo
37B VirtualQuery
23A LCMapStringA
387 WideCharToMultiByte
26B MultiByteToWideChar
23B LCMapStringW
198 GetProcAddress
34F TerminateProcess
13A GetCurrentProcess
30E SetFilePointer
E5 FlushFileBuffers
317 SetHandleCount
208 HeapCreate
USER32.dll
100121A0 Import Address Table
10016EA4 Import Name Table
0 time date stamp
0 Index of first forwarder reference
1DE MessageBoxA
216 RegisterClassA
60 CreateWindowExA
13A GetMessageA
2AA TranslateMessage
2B5 UnregisterDeviceNotification
99 DestroyWindow
203 PostQuitMessage
21C RegisterDeviceNotificationA
8E DefWindowProcA
201 PostMessageA
A1 DispatchMessageA
ADVAPI32.dll
10012000 Import Address Table
10016D04 Import Name Table
0 time date stamp
0 Index of first forwarder reference
1E2 RegOpenKeyExA
1CD RegCreateKeyExA
1F9 RegSetValueExA
1E1 RegOpenKeyA
1EC RegQueryValueExA
1C9 RegCloseKey
55 ConvertStringSecurityDescriptorToSecurityDescriptorA
SHELL32.dll
10012198 Import Address Table
10016E9C Import Name Table
0 time date stamp
0 Index of first forwarder reference
AF SHGetFolderPathA
Summary
3000 .data
6000 .rdata
2000 .reloc
1000 .rsrc
11000 .text

Resources