> > I suspect that it's a problem with either the --kaslr offset and/or > > the phys_base value that you have used. > > Is there method to know or print kaslr & phy_base in a running Linux system? They are normally passed in the VMCOREINFO data that is contained in an ELF PT_NOTE in the dumpfile header. For example, here's a dump of the normal VMCOREINFO data, where the phys_base and KASLR offsets are down near the bottom: OSRELEASE=4.18.0-185.el8.x86_64 PAGESIZE=4096 SYMBOL(init_uts_ns)=ffffffffbd812540 SYMBOL(node_online_map)=ffffffffbda0f520 SYMBOL(swapper_pg_dir)=ffffffffbd80a000 SYMBOL(_stext)=ffffffffbc600000 SYMBOL(vmap_area_list)=ffffffffbd8d78b0 SYMBOL(mem_section)=ffff956a3ffd2000 LENGTH(mem_section)=2048 SIZE(mem_section)=16 OFFSET(mem_section.section_mem_map)=0 SIZE(page)=64 SIZE(pglist_data)=171968 SIZE(zone)=1472 SIZE(free_area)=88 SIZE(list_head)=16 SIZE(nodemask_t)=128 OFFSET(page.flags)=0 OFFSET(page._refcount)=52 OFFSET(page.mapping)=24 OFFSET(page.lru)=8 OFFSET(page._mapcount)=48 OFFSET(page.private)=40 OFFSET(page.compound_dtor)=16 OFFSET(page.compound_order)=17 OFFSET(page.compound_head)=8 OFFSET(pglist_data.node_zones)=0 OFFSET(pglist_data.nr_zones)=171232 OFFSET(pglist_data.node_start_pfn)=171240 OFFSET(pglist_data.node_spanned_pages)=171256 OFFSET(pglist_data.node_id)=171264 OFFSET(zone.free_area)=192 OFFSET(zone.vm_stat)=1296 OFFSET(zone.spanned_pages)=112 OFFSET(free_area.free_list)=0 OFFSET(list_head.next)=0 OFFSET(list_head.prev)=8 OFFSET(vmap_area.va_start)=0 OFFSET(vmap_area.list)=48 LENGTH(zone.free_area)=11 SYMBOL(log_buf)=ffffffffbd85b140 SYMBOL(log_buf_len)=ffffffffbd85b13c SYMBOL(log_first_idx)=ffffffffbe319778 SYMBOL(clear_idx)=ffffffffbe319744 SYMBOL(log_next_idx)=ffffffffbe319768 SIZE(printk_log)=16 OFFSET(printk_log.ts_nsec)=0 OFFSET(printk_log.len)=8 OFFSET(printk_log.text_len)=10 OFFSET(printk_log.dict_len)=12 LENGTH(free_area.free_list)=5 NUMBER(NR_FREE_PAGES)=0 NUMBER(PG_lru)=5 NUMBER(PG_private)=12 NUMBER(PG_swapcache)=9 NUMBER(PG_swapbacked)=18 NUMBER(PG_slab)=8 NUMBER(PG_hwpoison)=22 NUMBER(PG_head_mask)=32768 NUMBER(PAGE_BUDDY_MAPCOUNT_VALUE)=-129 NUMBER(HUGETLB_PAGE_DTOR)=2 NUMBER(PAGE_OFFLINE_MAPCOUNT_VALUE)=-257 ===============> NUMBER(phys_base)=16437477376 SYMBOL(init_top_pgt)=ffffffffbd80a000 NUMBER(pgtable_l5_enabled)=0 SYMBOL(node_data)=ffffffffbda0ad20 LENGTH(node_data)=1024 ===============> KERNELOFFSET=3b600000 NUMBER(KERNEL_IMAGE_SIZE)=1073741824 NUMBER(sme_mask)=0 CRASHTIME=1583350919 But in your Azure-generated dumpfile, I note that each cpu's NT_PRSTATUS note contains junk data, and while does have a VMCOREINFO note, it contains this: Elf64_Nhdr: n_namesz: 11 ("VMCOREINFO") n_descsz: 42 n_type: 0 (unused) FAKE1=IGNORE1 FAKE2=IGNORE2 FAKE3=IGNORE3 So that's why you need to pass in the two arguments. Now, the crash utility should be able to be brought up successfully on a live system without passing the arguments. And once you've done that, you could get the values like this: crash> help -m | grep phys_base phys_base: 3d3c00000 crash> help -k | grep relocate relocate: ffffffffc4a00000 (KASLR offset: 3b600000 / 950MB) crash> But since they change with each reboot, you would have to capture them while running on the live system, and save them somewhere for a subsequent crash. So that goes back to my question -- how did you get the numbers that you used? Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility