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.
Related
I am debugging windows kernel with windbg, but the problem is that when windows goes to repair mode when it detect an error during booting, and goes to repair mode, i don't attach to kernel at all to begin with.
But obviously the kernel has already loaded, and it already has detected a problem, so why am i not getting attach to it before the error is getting detected? how can i attach to it?
Note that the error is not a major one, i caused it myself for testing purposes, its because of an self signed driver in the boot driver list, and i need to attach to kernel before it detect this problem, how can i do this? I need to find which function/module is detecting this problem.
Currently i am attaching via COM pipe, the connection is between two VMs in VMware.
kd> sxe ld:nt
kd> sxe ibp;.reboot
Shutdown occurred at (Wed Apr 7 02:14:59.871 2021 (UTC + 5:30))...unloading all symbol tables.
Waiting to reconnect...
BD: Boot Debugger Initialized
Connected to Windows Boot Debugger 17763 x64 target at
Kernel Debugger connection established. (Initial Breakpoint requested)
broke on nt module load
Windows 10 Kernel Version 17763 MP (1 procs) Free x64
Built by: 17763.1.amd64fre.rs5_release.180914-1434
Machine Name:
Kernel base = 0xfffff800`5e204000 PsLoadedModuleList = 0xfffff800`5e61f9f0
System Uptime: 0 days 0:00:00.000
nt!DebugService2+0x5:
fffff800`5e3bf295 cc int 3
stack and loading module name
kd> k;ds#rcx
# Child-SP RetAddr Call Site
00 fffff800`60a82de8 fffff800`5e294df5 nt!DebugService2+0x5
01 fffff800`60a82df0 fffff800`5eb19be2 nt!DbgLoadImageSymbols+0x45
02 fffff800`60a82e40 fffff800`5e76917c nt!KdInitSystem+0xaa2
03 fffff800`60a82fc0 00000000`00000000 nt!KiSystemStartup+0x16c
fffff800`60a82e70 "\SystemRoot\system32\ntoskrnl.ex"
fffff800`60a82e90 "e"
bp as requested
kd> bp nt!IopLoadDriver
kd> bl
0 e Disable Clear fffff800`5e869020 0001 (0001) nt!IopLoadDriver
you may also need gflag +ksl
anyway sxe ld:nt breaking on ntfs.sys load a little alter and stack
kd> r
rax=0000000000000003 rbx=fffff80060a82200 rcx=fffff80060a82200
rdx=fffff80060a821b0 rsi=fffff8005fe00000 rdi=fffff8005d26f940
rip=fffff8005e3bf295 rsp=fffff80060a82188 rbp=fffff80060a82320
r8=0000000000000003 r9=fffff80060a82198 r10=0000000000000000
r11=fffff8005d17dbd0 r12=0000000000000000 r13=fffff8005d1515f0
r14=0000000000000001 r15=fffff80e62170000
iopl=0 nv up ei ng nz na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000286
nt!DebugService2+0x5:
fffff800`5e3bf295 cc int 3
kd> ds #rcx
ffffbd0f`f003fa20 "Ntfs.sys"
kd> k
# Child-SP RetAddr Call Site
00 fffff800`60a82188 fffff800`5e294df5 nt!DebugService2+0x5
01 fffff800`60a82190 fffff800`5e294d87 nt!DbgLoadImageSymbols+0x45
02 fffff800`60a821e0 fffff800`5ebbdd47 nt!DbgLoadImageSymbolsUnicode+0x2b
03 fffff800`60a82220 fffff800`5ebbc9ea nt!MiReloadBootLoadedDrivers+0x45f
04 fffff800`60a823b0 fffff800`5ebc266d nt!MiInitializeDriverImages+0x192
05 fffff800`60a82460 fffff800`5ebc228d nt!MiInitSystem+0x3a5
06 fffff800`60a82500 fffff800`5ebbb463 nt!MmInitSystem+0x89
07 fffff800`60a82530 fffff800`5e7745fb nt!InitBootProcessor+0x47b
08 fffff800`60a82750 fffff800`5e769219 nt!KiInitializeKernel+0x50b
09 fffff800`60a82a50 00000000`00000000 nt!KiSystemStartup+0x209
a sample load sequence with sxe ld:*
kd> .lastevent
Last event: Load module winload.efi at 00000000`00844000
debugger time: Wed Apr 7 02:35:18.275 2021
kd> r
rax=0000000000000003 rbx=00000000001a6cc0 rcx=00000000001a6cc0
rdx=00000000001a6c60 rsi=00000000009cdb60 rdi=0000000000000000
rip=0000000000992c15 rsp=00000000001a6c38 rbp=00000000001a6d19
r8=0000000000000003 r9=00000000001a6c98 r10=0000000000000000
r11=0000000000000000 r12=0000000000000001 r13=0000000000000002
r14=00000000001a7801 r15=0000000000000000
iopl=0 nv up di pl nz na po nc
cs=0010 ss=0000 ds=0030 es=0030 fs=0030 gs=0030 efl=00000006
winload!DebugService2+0x5:
00000000`00992c15 cc int 3
kd> kb
# RetAddr : Args to Child : Call Site
00 00000000`008717d2 : : winload!DebugService2+0x5
01 00000000`0092b413 : : winload!DbgLoadImageSymbols+0x62
02 00000000`0092b8d0 : : winload!BlBdStart+0x197
03 00000000`008c68ac : : winload!BlBdInitialize+0x304
04 00000000`008c5708 : : winload!InitializeLibrary+0x4dc
05 00000000`008451bb : : winload!BlInitializeLibrary+0x8c
06 00000000`10137ea6 : : winload!OslMain+0x12b
07 00000000`00000000 : : 0x10137ea6
kd> g
Shutdown occurred at (Wed Apr 7 02:36:10.939 2021
Waiting to reconnect...
BD: Boot Debugger Initialized
Connected to Windows Boot Debugger 17763 x64 target at
Kernel Debugger connection established. (Initial Breakpoint requested)
Windows Boot Debugger Kernel Version 17763 UP Free x64
Machine Name:
Primary image base = 0x00000000`00844000 Loaded module list = 0x00000000`009cdb60
System Uptime: not available
winload!DebugService2+0x5:
00000000`00992c15 cc int 3
kd> ds#rcx
00000000`001a62a0 "winload.efi"
kd> g
Shutdown occurred at
Waiting to reconnect...
Connected to Windows 10 17763 x64 target at
Kernel Debugger connection established. (Initial Breakpoint requested)
Windows 10 Kernel Version 17763 MP (1 procs) Free x64
Built by: 17763.1.amd64fre.rs5_release.180914-1434
Machine Name:
Kernel base = 0xfffff802`26ea8000 PsLoadedModuleList = 0xfffff802`272c39f0
System Uptime: 0 days 0:00:00.000
nt!DebugService2+0x5:
fffff802`27063295 cc int 3
kd> ds#rcx
fffff802`29682e70 "\SystemRoot\system32\ntoskrnl.ex"
fffff802`29682e90 "e"
kd> g
nt!DebugService2+0x5:
fffff802`27063295 cc int 3
kd> ds#rcx
fffff802`29682e70 "\SystemRoot\system32\hal.dll"
kd> g
nt!DebugService2+0x5:
fffff802`27063295 cc int 3
kd> ds#rcx
fffff802`29682e70 "\SystemRoot\system32\kdcom.dll"
kd> g
nt!DebugService2+0x5:
fffff802`27063295 cc int 3
kd> ds#rcx
ffffca87`69a44f00 "mcupdate.dll"
kd> g
nt!DebugService2+0x5:
fffff802`27063295 cc int 3
kd> ds#rcx
ffffca87`69a44f60 "msrpc.sys"
kd> g
nt!DebugService2+0x5:
fffff802`27063295 cc int 3
kd> ds#rcx
ffffca87`69a44fc0 "ksecdd.sys"
kd> g
nt!DebugService2+0x5:
fffff802`27063295 cc int 3
kd> ds#rcx
ffffca87`69a43c80 "werkernel.sys"
kd> g
nt!DebugService2+0x5:
fffff802`27063295 cc int 3
kd> ds#rcx
ffffca87`69a43ce0 "CLFS.SYS"
kd> g
nt!DebugService2+0x5:
fffff802`27063295 cc int 3
kd> ds#rcx
ffffca87`69a43d40 "tm.sys"
updated to address the comments
as I commented you need to know where to set the breakpoint or you need to manually trace (and bugcheck , go through not booted several times , automatic repair etc )
shown below is an initial break and a manual break on winload.efi
kd> .reboot
Shutdown occurred at (Wed Mar 17 23:21:19.732 2021 )...unloading all symbol tables.
Waiting to reconnect...
BD: Boot Debugger Initialized
Connected to Windows Boot Debugger 17763 x64 target at (Wed Mar 17 23:21:24.259 2021 ), ptr64 TRUE
Kernel Debugger connection established. (Initial Breakpoint requested)
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*f:\symbols*https://msdl.microsoft.com/download/symbols
Symbol search path is: srv*f:\symbols*https://msdl.microsoft.com/download/symbols
Executable search path is:
ReadVirtual() failed in GetXStateConfiguration() first read attempt (error == 0.)
Windows Boot Debugger Kernel Version 17763 UP Free x64
Machine Name:
Primary image base = 0x00000000`00844000 Loaded module list = 0x00000000`009cdb60
System Uptime: not available
winload!DebugService2+0x5:
00000000`00992c15 cc int 3
kd> kb
# RetAddr : Args to Child : Call Site
00 00000000`008717d2 : 00000000`00000001 00000000`001a6d19 00000000`00000000 00000000`00992be5 : winload!DebugService2+0x5
01 00000000`0092b413 : fffff806`63301780 00000000`008440f0 00000000`009cdb60 00000000`00000000 : winload!DbgLoadImageSymbols+0x62
02 00000000`0092b8d0 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : winload!BlBdStart+0x197
03 00000000`008c68ac : 000007ff`ffffd000 00000000`00000000 00000000`00000000 00000000`001a7000 : winload!BlBdInitialize+0x304
04 00000000`008c5708 : 00000000`895443e8 00000000`0001a014 00000000`001a6f79 00000000`00000000 : winload!InitializeLibrary+0x4dc
05 00000000`008451bb : 00000000`001a7000 00000000`00000000 00000000`00000000 00000000`00000000 : winload!BlInitializeLibrary+0x8c
06 00000000`10137ea6 : 00000000`00000000 00000000`00000000 00000000`001a7000 00000000`00000000 : winload!OslMain+0x12b
07 00000000`00000000 : 00000000`00000000 00000000`001a7000 00000000`00000000 50504120`544f4f42 : 0x10137ea6
kd> bp winload!OslpMain
kd> g
Breakpoint 0 hit
winload!OslpMain:
00000000`00846174 48895c2408 mov qword ptr [rsp+8],rbx
kd> kb
# RetAddr : Args to Child : Call Site
00 00000000`008451cc : 00000000`001a7000 00000000`00000000 00000000`00000000 00000000`00000000 : winload!OslpMain
01 00000000`10137ea6 : 00000000`00000000 00000000`00000000 00000000`001a7000 00000000`00000000 : winload!OslMain+0x13c
02 00000000`00000000 : 00000000`00000000 00000000`001a7000 00000000`00000000 50504120`544f4f42 : 0x10137ea6
you can check what are the calls that may get executed using uf as below
kd> uf /c winload!OslMain
winload!OslMain (00000000`00845090)
winload!OslMain+0x46 (00000000`008450d6):
call to winload!strcmp (00000000`0098a220)
winload!OslMain+0xe0 (00000000`00845170):
call to winload!memset (00000000`00994700)
winload!OslMain+0x126 (00000000`008451b6):
call to winload!BlInitializeLibrary (00000000`008c567c)
winload!OslMain+0x137 (00000000`008451c7):
call to winload!OslpMain (00000000`00846174)
winload!OslMain+0x147 (00000000`008451d7):
call to winload!BlDestroyLibrary (00000000`008c5714)
Programmatic removing of files to Recycle Bin in Windows is a trivial operation.
In short: just move a file to
C:\$Recycle.Bin\SID\$R{name}* (for drive C) and create an associated binary file ($I{name}) with meta information about the "deleted" file/folder near it.
* where SID is your OS installation identifier that looks like: S-1-5-21-1234567890-1234567890-1234567890-1001.
But I have two question after researching:
What is the algorithm of encoding the deletion date to 64-bit value?
Are the file names (in a trash bin) random generated or there is some logic?
The information file structure is follow (based on my research):
const buffer = new Uint8Array([
0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // Header
0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // Size // 65535 (bytes)
0x00, 0x00, 0x00, 0x00, 0x00, 0x30, 0xd7, 0x01, // Deletion date (64-bit value)
0x0b, 0x00, 0x00, 0x00, // Path string length // `11`
0x43, 0x00, 0x3a, 0x00, // File path + \0 // `C:\1\1.txt` // `C:\\1\\1.txt\0`
0x5c, 0x00, 0x31, 0x00, 0x5c, 0x00, 0x31, 0x00,
0x2e, 0x00, 0x74, 0x00, 0x78, 0x00, 0x74, 0x00,
0x00, 0x00
]);
Header (always is the same), file size in bytes (which is only visible in File Explorer), 64-bit deletion date value, path string length, and UTF-16 encoded null-terminated path string.
The only questionable part is the date. How is it encoded?
For example:
00 00 00 00 00 29 d7 01 is 2021.04.04 03:10
00 00 00 00 01 29 d7 01 is 2021.04.04 03:17
00 00 00 00 00 30 d7 01 is 2021.04.13 00:57
(The first four hexes is 00 just for convenience.)
For example: 00 00 00 00 00 29 d7 01 is 132619794007457792, but new Date(132619794007457792/100000) is 2012.01.10 12:19:00.
I need to transform 00 00 00 00 00 29 d7 01 bytes to 2021.04.04 03:10.
The "deleted" files in C:\$Recycle.Bin\SID\ have name that is started with $R + [A-Z0-9]{7} + optional .{extension}.
For example: $RL6JQMF.txt.
And associated meta data file: $IL6JQMF.txt that just starts with $I.
Is there some logic for the naming or it is just a random generated one?
In fact, for example, it works well with both $R___ + $I___, and with $R123456789 abc + $I123456789 abc. So, I think it is just random generated.
Only the $R/$I is required. The extension is needed only just to shows the corresponding icon in the File Explorer.
Okay, I got it.
While
00 00 00 00 00 00 00 00 is 1899.12.30 00:00,
but 00 00 00 00 00 00 01 00 is 1601.11.22 18:44,
so this timestamp is a number of 100-nanosecond intervals since 1601.01.01.
For example, for 00 00 00 00 00 29 d7 01 (132619794007457792) I get the correct date (2021.04.04 03:10) as it shows in File Explorer with:
new Date(132619794007457792 / 10000 + Number(new Date("1601.01.01 Z")))
Anyway, I think this topic would be useful for people.
It's strange that in 2021 I did not found any info about how Recycle Bin in Windows works.
Ive done some extensive research on this, as it seems, surprisingly, there is very few info available online on how Recycle Bin actually implemented.
Everything is not that hard to grasp. When you delete file in the Bin, it is not actually moved to it.
First, lets take a look at the subfolders of $Recycle.Bin:
C:\$Recycle.Bin\S-1-5-18 is folder for built-in SYSTEM account
C:\$Recycle.Bin\S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-1XXX\, starting from 1000 are non-built in user folders. You should first check which one of them is the one you need by typing whoami /all in command prompt to get your SID, or wmic useraccount get name,sid to get all local accounts SIDs, then choose the folder matching with SID.
If you give security rights to your account to all this folders, Explorer might show your deleted files in every folder, however its just Explorer bug. If you navigate to, say, C:\$Recycle.Bin\S-1-5-18 folder and type dir /a, you will see that its actually empty, and only folder that match with your SID contains your deleted files.
Note that even if you are the only user on the PC, you might still have folder C:\$Recycle.Bin\S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-1000\ that most likely will be empty. Then your actual folder will be ...-1001\. User "1000" seems to be dangling folder for user that was created automatically by Windows on installation or some updates, then deleted. But Recycle.Bin folder wasn't destroyed and just stayed there. I assume that its safe to delete this dangling folder. I'm not so sure about C:\$Recycle.Bin\S-1-5-18, but I'm fairly sure its safe too, as there is no need for OS SYSTEM account to use the Bin, anyway.
So, here is deletion algorithm:
System creates hardlink of the deleted file in C:\$Recycle.Bin\S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-1XXX\ folder with the name $RXXXXXX.<file_ext>, where XXXXXX is 6 symbols HASH calculated based on the file contents, as I assume.
Metadata file is created in the same folder with the name $IXXXXXX.<file_ext>. I will show you the content of this file later.
Original file is deleted, but because of extra hardlink in $Recycle.Bin, actual file's data stays in the same location on the drive as if file where never touched. It is not moved anywhere. This is why each logical volume must have it's own $Recycle.Bin folder, as hardlinks only work within the same volume.
That's about it. Restoration algorithm:
Metadata file is read and hardlink of $RXXXXXX.<file_ext> is created based on $IXXXXXX.<file_ext>'s info in original file location, with original file name.
Both metadata and backup file are deleted from $Recycle.Bin
Pretty simple, ain't it?
Now, the most interesting part is that metadata file:
0000 02 00 00 00 00 00 00 00 <-- File header (QW)
0008 00 7C 0A 00 00 00 00 00 <-- File size (QW)
0010 90 83 72 44 28 9C D8 01 <-- File deletion date (QW)
0018 18 00 00 00|43 00 3A 00 <-- File path string length (DW)
0020 5C 00 24 00 52 00 65 00
0028 63 00 79 00 63 00 6C 00
0030 65 00 2E 00 42 00 69 00
0038 6E 00 5C 00 66 00 73 00
0040 73 00 2E 00 65 00 78 00
0048 65 00 00 00| <-- |Null-terminated path string| (wchar_t)
All values are in Little Endian format.
Header is fixed and its identical for all the files. Be warned that some $I files might have some junk bytes FF FE appear before the Header. I have no idea what are this for, so you should check for full header before reading further.
Deletion date is in FILETIME format and can be converted to usual SYSTEMTIME via FileTimeToSystemTime. It represents 100-nanosecond intervals since January 1, 1601 (UTC).
So it's not super complicated file format, but quite interesting design.
I'm planing to use this info myself by creating custom "garbage collector" for Windows, that I will add to task scheduler to launch periodically and scan\delete files that where deleted more than 24 hours ago, etc. I know that Windows 10 has built-in option for this, but it's not flexible and not reliable (it sometimes leaves metadata files, while only deleteing $R files). Also, I think, previous Windows versions doesn't have this feature at all.
I encourage you to experiment with this too! For example, your program might save metadata info of all files it removes into some database, so you would have full history of all files you ever deleted!
I want to use SymGetSourceFile to get a source file from source server using info from a dump file. But the first param is a handle to process but during postmortem we dont have a process, so is it meant to be used only for live debugging tools? How can I use it from a postmortem debugging tool?
BOOL IMAGEAPI SymGetSourceFile(
HANDLE hProcess,
ULONG64 Base,
PCSTR Params,
PCSTR FileSpec,
PSTR FilePath,
DWORD Size
);
https://learn.microsoft.com/en-us/windows/win32/api/dbghelp/nf-dbghelp-symgetsourcefile
Update:
I have tried using IDebugAdvanced3 interface for same but get HR = 0x80004002 for GetSourceFileInformation call.
char buf[1000] = { 0 };
HRESULT hr = g_ExtAdvanced->GetSourceFileInformation(DEBUG_SRCFILE_SYMBOL_TOKEN,
"Application.cs",
0x000000dd6f5f1000, 0, buf, 1000, 0);
if (SUCCEEDED(hr))
{
dprintf("GetSourceFileInformation = %s", buf);
char buftok[5000] = { 0 };
hr = g_ExtAdvanced->FindSourceFileAndToken(0, 0x000000dd6f5f1000,
"Application.cs", DEBUG_FIND_SOURCE_TOKEN_LOOKUP,
buf, 1000, 0, buftok, 5000, 0);
if (SUCCEEDED(hr))
{
dprintf("FindSourceFileAndToken = %s", buf);
}
else
dprintf("FindSourceFileAndToken HR = %x", hr);
}
else
dprintf("GetSourceFileInformation HR = %x", hr);
I have dump that has this module and pdb loaded. and pass an address within the module - 0x000000dd6f5f1000, to GetSourceFileInformation
this was a comment but grew up so addingas answer
GetSourceFileINformation iirc checks the source servers those that start with srv or %srcsrv%
this returns a token for use with findsourcefileandtoken
if you have a known offset (0x1070 == main() in case below )
use GetLineByOffset this has the added advantage of reloading all the modules
hope you have your private pdb for the dump file you open.
this is engext syntax
Hr = m_Client->OpenDumpFile("criloc.dmp");
Hr = m_Control->WaitForEvent(0,INFINITE);
unsigned char Buff[BUFFERSIZE] = {0};
ULONG Buffused = 0;
DEBUG_READ_USER_MINIDUMP_STREAM MiniStream ={ModuleListStream,0,0,Buff,BUFFERSIZE,Buffused};
Hr = m_Advanced2->Request(DEBUG_REQUEST_READ_USER_MINIDUMP_STREAM,&MiniStream,sizeof(
DEBUG_READ_USER_MINIDUMP_STREAM),NULL,NULL,NULL);
MINIDUMP_MODULE_LIST *modlist = (MINIDUMP_MODULE_LIST *)&Buff;
Hr = m_Symbols->GetLineByOffset(modlist->Modules[0].BaseOfImage+0x1070,&Line,
FileBuffer,0x300,&Filesize,&Displacement);
Out("getlinebyoff returned %x\nsourcefile is at %s line number is %d\n",Hr,FileBuffer,Line);
this is part src adapt it to your needs.
the result of the extension command is pasted below
0:000> .load .\mydt.dll
0:000> !mydt
Loading Dump File [C:\Users\xxxx\Desktop\srcfile\criloc.dmp]
User Mini Dump File with Full Memory: Only application data is available
OpenDumpFile Returned 0
WaitForEvent Returned 0
Request Returned 0
Ministream Buffer Used 28c
06 00 00 00 00 00 8d 00 00 00 00 00 00 e0 04 00
f0 9a 05 00 2d 2e a8 5f ba 14 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 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
43 00 00 00 4a 38 00 00 00 00 00 00 00 00 00 00
40 81 00 00 00 00 00 00 00 00 00 00 00 00 00 00
No of Modules =6
Module[0]
Base = 8d0000
Size = 4e000
getlinebyoff returned 0
sourcefile is at c:\users\xxx\desktop\misc\criloc\criloc.cpp line number is 21 <<<<<<<<<
||1:1:010> lm
start end module name
008d0000 0091e000 CRILOC (private pdb symbols) C:\Users\xxxx\Desktop\misc\CRILOC\CRILOC.pdb
||1:1:010>
and the actual source file contents on path
:\>grep -i -n main CRILOC.CPP
20:int main(void) << the curly braces is on line 21
UPDATE:
yes if the src file is not source indexed (cvs,perforce,... ) GetSourceFileInformation () will not return a token
it checks for a token using the Which parameter
and the returned info can be used in FindSourceFileAndToken();
if your source is not source indexed and you only have a source path
use FindSourceFileandToken() with DEBUG_FIND_SOURCE_FULL_PATH Flag
be aware you need to either use SetSourcePath() or issue .srcpath command or use _NT_SOURCE_PATH environment variable or use -srcpath commandline switch prior to invoking FindSourceFileAndToken()
see below for a walkthrough
sourcefile and contents
:\>ls *.cpp
mydt.cpp
:\>cat mydt.cpp
#include <engextcpp.cpp>
#define BSIZE 0x1000
class EXT_CLASS : public ExtExtension {
public:
EXT_COMMAND_METHOD(mydt);
};
EXT_DECLARE_GLOBALS();
EXT_COMMAND( mydt, "mydt", "{;e,o,d=0;!mydt;}" ){
HRESULT Hr = m_Client->OpenDumpFile("criloc.dmp");
Hr = m_Control->WaitForEvent(0,INFINITE);
char Buff[BSIZE] = {0};
ULONG Buffused = 0;
DEBUG_READ_USER_MINIDUMP_STREAM MiniStream ={ModuleListStream,0,0,
Buff,BSIZE,Buffused};
Hr = m_Advanced2->Request(DEBUG_REQUEST_READ_USER_MINIDUMP_STREAM,&MiniStream,
sizeof(DEBUG_READ_USER_MINIDUMP_STREAM),NULL,NULL,NULL);
MINIDUMP_MODULE_LIST *modlist = (MINIDUMP_MODULE_LIST *)&Buff;
//m_Symbols->SetSourcePath("C:\\Users\\xxx\\Desktop\\misc\\CRILOC");
char srcfilename[BSIZE] ={0};
ULONG foundsize =0 ;
Hr = m_Advanced3->FindSourceFileAndToken(0,modlist->Modules[0].BaseOfImage,"criloc.cpp",
DEBUG_FIND_SOURCE_FULL_PATH,NULL,0,NULL,srcfilename,0x300,&foundsize);
Out("gsfi returned %x\n" , Hr);
Out("srcfilename is %s\n",srcfilename);
}
compiled and linked with
:\>cat bld.bat
#echo off
set "INCLUDE= %INCLUDE%;E:\windjs\windbg_18362\inc"
set "LIB=%LIB%;E:\windjs\windbg_18362\lib\x86"
set "LINKLIBS=user32.lib kernel32.lib dbgeng.lib dbghelp.lib"
cl /LD /nologo /W4 /Od /Zi /EHsc mydt.cpp /link /nologo /EXPORT:DebugExtensionInitialize /Export:mydt /Export:help /RELEASE %linklibs%
:\>bld.bat
mydt.cpp
E:\windjs\windbg_18362\inc\engextcpp.cpp(1849): warning C4245: 'argument': conversion from 'int' to 'ULONG64', signed/unsigned mismatch
Creating library mydt.lib and object mydt.exp
:\>file mydt.dll
mydt.dll; PE32 executable for MS Windows (DLL) (GUI) Intel 80386 32-bit
executing
:\>cdb cdb
Microsoft (R) Windows Debugger Version 10.0.18362.1 X86
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
ntdll!LdrpDoDebuggerBreak+0x2c:
77d805a6 cc int 3
0:000> .load .\mydt.dll
0:000> .chain
Extension DLL chain:
.\mydt.dll: API 1.0.0, built Thu Mar 18 20:40:04 2021
[path: C:\Users\xxxx\Desktop\srcfile\New folder\mydt.dll]
0:000> !mydt
Loading Dump File [C:\Users\xxxx\Desktop\srcfile\New folder\criloc.dmp]
User Mini Dump File with Full Memory: Only application data is available
gsfi returned 80004002
srcfilename is
||1:1:010> .srcpath "c:\\users\\xxxx\\desktop\\misc\\criloc\\"
Source search path is: c:\\users\\xxxx\\desktop\\misc\\criloc\\
************* Path validation summary **************
Response Time (ms) Location
OK c:\\users\\xxxx\\desktop\\misc\\criloc\\
||1:1:010> !mydt
Loading Dump File [C:\Users\xxxx\Desktop\srcfile\New folder\criloc.dmp]
gsfi returned 0
srcfilename is c:\\users\\xxxx\\desktop\\misc\\criloc\\criloc.cpp
||2:2:021>
Well the following should work - I can't find a reason why it shouldn't:
std::fstream f;
std::string myoutput;
f.imbue(std::locale(f.getloc(), new std::codecvt_utf16<wchar_t, std::little_endian | std::consume_header>));
f.open("c:\\test.txt", std::ios::in);
std::getline(f, myoutput);
The code is executed on the following file (in hex - it should spell "hello world"):
FF FE 68 00 65 00 6C 00 6C 00 6F 00 20 00 77 00 6F 00 72 00 6C 00 64
00
The ultimate goal is to abstract the encoding away, always consider a file UTF-8 unless the first bytes are a BOM. Now above code would be executed after reading a BOM and noticing it is UTF-16. It should hence read UTF-16 file, and convert it to a utf-8 string.
However the std::getline does not ignore the BOM (easily fixed) but furthermore it does not respect the fact that UTF-16 uses 2 bytes. (And it stops after reading the first 3 bytes upon seeing "0" ).
Now of course I could use std::wfstream. But as I wish to "hide" the unicode type from the user for one thing all the "filestreams" are stored inside a container for referencing. So the signature of all those filestreams has to be equal - and be based on char and std::string
If you opened your file as basic_fstream<char>, you've already set both external and internal character width to 1 byte and the locale facet you're applying will never be used.
Either read into a string and apply wstring_convert twice, or apply wbuffer_convert to make the internal character width bigger, and then wstring_convert:
std::fstream f;
f.open("test.txt", std::ios::in | std::ios::binary);
std::wbuffer_convert<std::codecvt_utf16<wchar_t,
0x10ffff, // note your 2nd parameter was wrong
std::little_endian // or consume_header, not both
>> cvt1(f.rdbuf());
std::wistream wide_f(&cvt1);
std::wstring wstr;
std::getline(wide_f, wstr);
std::wstring_convert<std::codecvt_utf8<wchar_t>> cvt2;
std::string u8str = cvt2.to_bytes(wstr);
std::cout << u8str << '\n';
My ultimate goal is to compile rtorrent for my NAS which is a Synology DS107+. To familiarize myself with cross compiling, I wanted to compile a helloworld. This already turned out to be a big hurdle for a novice as I am.
Executing the program results in a Segmentation Fault. I used gcc-arm-none-eabi to compile it on Ubuntu x84_64.
What tools do I need to compile a program for the target? I also consulted "Cross compile from linux to ARM-ELF (ARM926EJ-S/MT7108)" and needed a workaround, because gcc complained that _exit is not declared.
Following, there is more detailed information:
/proc/cpuinfo
Processor : ARM926EJ-Sid(wb) rev 0 (v5l)
BogoMIPS : 499.71
Features : swp half thumb fastmult vfp edsp
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part : 0x926
CPU revision : 0
Cache type : write-back
Cache clean : cp15 c7 ops
Cache lockdown : format C
Cache format : Harvard
I size : 32768
I assoc : 1
I line length : 32
I sets : 1024
D size : 32768
D assoc : 4
D line length : 32
D sets : 256
Hardware : MV-88fxx81
Revision : 0000
Serial : 0000000000000000
uname -a
Linux DiskStation 2.6.15 #1637 Sat May 4 05:59:19 CST 2013
armv5tejl GNU/Linux synology_88f5281_107+
dmesg (snippets from head that seem informative to me)
Linux version 2.6.15 (root#build2) (gcc version 3.4.3 (CSL 2005Q1B) (Marvell 2006Q3))
#1637 Sat May 4 05:59:19 CST 2013
CPU: ARM926EJ-Sid(wb) [41069260] revision 0 (ARMv5TEJ)
Machine: MV-88fxx81
...
Synology Hareware Version: DS107v20
Memory policy: ECC disabled, Data cache writeback
...
CPU0: D VIVT write-back cache
CPU0: I cache: 32768 bytes, associativity 1, 32 byte lines, 1024 sets
CPU0: D cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets
readelf -h busybox (pulled from the device)
ELF Header:
Magic: 7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: ARM
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x8de0
Start of program headers: 52 (bytes into file)
Start of section headers: 1319468 (bytes into file)
Flags: 0x602, has entry point, GNU EABI, software FP, VFP
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 3
Size of section headers: 40 (bytes)
Number of section headers: 20
Section header string table index: 19
EDIT: Command line
I used the options -march=armv5te -mtune=arm926ej-s -mno-long-calls -msoft-float -static. I also experimented with leaving out march oder replaced mtune by mcpu. Without static, it says not found. Also tried -mfpu=vfp and armel binaries of Debian packages. For example busybox-static which runs fine on my HTC Desire S (armv7l), also results in segfault.
Using:
arm-linux-gnueabi-gcc → Segmentation fault
arm-none-eabi-gcc → Segmentation fault (or Illegal instruction, but rarely, can't tell when)
Haven't tried CodeBench, yet.
The code I tried is:
# include <stdlib.h>
void _exit (int x) { while (1) {} } // only needed for arm-none-eabi-gcc
int main (int argc, char* argv[]) {
return 47;
}