Hello Wine users!
I've got a minidump from a ("real") Windows user of our game and would like to extract information from it using winedbg.
The information winedbg gives me by default, is this:
WineDbg starting on minidump on pid 068c warzone2100.exe was running on #1 Intel ???-0.521 CPU on Windows XP (2600) Register dump: CS:001b SS:0023 DS:0023 ES:0023 FS:003b GS:0000 EIP:0051008b ESP:0022f844 EBP:0022f858 EFLAGS:00010a87( - 00 ROISP1C) EAX:c7b054d8 EBX:19ff502e ECX:00000040 EDX:0000000f ESI:02010101 EDI:00000000 Stack dump: 0x0022f844: 00000000 00000000 00000000 3f800000 0x0022f854: 00000000 0022f8c8 0050e796 19ff502e 0x0022f864: 3f800000 00000000 00000000 00000000 0x0022f874: 00000000 00000000 00000000 ff4a4a4a 0x0022f884: 00000005 02010101 00000000 00000000 0x0022f894: 00000000 0022f8c8 00000000 00000000 Backtrace: =>1 0x0051008b (0x0022f858) 2 0x0050e796 (0x0022f8c8) 3 0x00410c3b (0x0022f948) 4 0x0041172d (0x0022f9c8) 5 0x004b2272 (0x0022f9d8) 6 0x004aa97b (0x0022f9f8) 7 0x004b615a (0x0022fab8) 8 0x004b663f (0x0022fad8) 9 0x004b67e1 (0x0022faf8) 10 0x0041e39e (0x0022fb28) 11 0x00459d3e (0x0022fb58) 12 0x0045b2ee (0x0022fca8) 13 0x0055e77b (0x0022fcf8) 14 0x0055e932 (0x0022fef8) 15 0x0055e483 (0x0022fff0) 16 0x00000000 (0x00000000) WineDbg starting on pid 068c
Which is pretty rare. Via addr2line I can translate the backtrace to possibly valid locations in our sourcefiles.
My questions are: - Why doesn't winedbg extract the sourcecode locations itself? - Why doesn't winedbg show me the other information included in the minidump, like the loaded modules, commandline options or version information? - How can I get the parameters to the last called function(s)?
If winedbg is missing the commands/functions to achive the above, I may be able to provide it. The minidump functions seem to be documented rather good on msdn and it would just require printing it to the console.
Thanks in advance, Dennis
Dennis Schridde a écrit :
Hello Wine users!
I've got a minidump from a ("real") Windows user of our game and would like to extract information from it using winedbg.
The information winedbg gives me by default, is this:
WineDbg starting on minidump on pid 068c warzone2100.exe was running on #1 Intel ???-0.521 CPU on Windows XP (2600) Register dump: CS:001b SS:0023 DS:0023 ES:0023 FS:003b GS:0000 EIP:0051008b ESP:0022f844 EBP:0022f858 EFLAGS:00010a87( - 00 ROISP1C) EAX:c7b054d8 EBX:19ff502e ECX:00000040 EDX:0000000f ESI:02010101 EDI:00000000 Stack dump: 0x0022f844: 00000000 00000000 00000000 3f800000 0x0022f854: 00000000 0022f8c8 0050e796 19ff502e 0x0022f864: 3f800000 00000000 00000000 00000000 0x0022f874: 00000000 00000000 00000000 ff4a4a4a 0x0022f884: 00000005 02010101 00000000 00000000 0x0022f894: 00000000 0022f8c8 00000000 00000000 Backtrace: =>1 0x0051008b (0x0022f858) 2 0x0050e796 (0x0022f8c8) 3 0x00410c3b (0x0022f948) 4 0x0041172d (0x0022f9c8) 5 0x004b2272 (0x0022f9d8) 6 0x004aa97b (0x0022f9f8) 7 0x004b615a (0x0022fab8) 8 0x004b663f (0x0022fad8) 9 0x004b67e1 (0x0022faf8) 10 0x0041e39e (0x0022fb28) 11 0x00459d3e (0x0022fb58) 12 0x0045b2ee (0x0022fca8) 13 0x0055e77b (0x0022fcf8) 14 0x0055e932 (0x0022fef8) 15 0x0055e483 (0x0022fff0) 16 0x00000000 (0x00000000) WineDbg starting on pid 068c
Which is pretty rare. Via addr2line I can translate the backtrace to possibly valid locations in our sourcefiles.
My questions are:
- Why doesn't winedbg extract the sourcecode locations itself?
because it needs the original PE files (.exe, .dll) to get to the debug information those files must be seated in directories listed in the _NT_SYMBOL_PATH environment variable
- Why doesn't winedbg show me the other information included in the minidump,
like the loaded modules, commandline options or version information?
'info share' should do part of it... winedbg doesn't show the command line info nor options other thing you can do is to use winedump (man winedump)
- How can I get the parameters to the last called function(s)?
see above for debug info A+
Am Donnerstag, 29. März 2007 schrieb Eric Pouech:
Dennis Schridde a écrit :
Hello Wine users!
I've got a minidump from a ("real") Windows user of our game and would like to extract information from it using winedbg.
The information winedbg gives me by default, is this:
[...]
Which is pretty rare. Via addr2line I can translate the backtrace to possibly valid locations in our sourcefiles.
My questions are:
- Why doesn't winedbg extract the sourcecode locations itself?
because it needs the original PE files (.exe, .dll) to get to the debug information those files must be seated in directories listed in the _NT_SYMBOL_PATH environment variable
Maybe I am just doing it wrong, but _NT_SYMBOL_PATH=. winedbg warzone2100.mdmp doesn't change anything... (Even supplying the full path doesn't.) The exe (not all dlls, because I don't have a copy of the user's system) is of course in the working directory.
- Why doesn't winedbg show me the other information included in the
minidump, like the loaded modules, commandline options or version information?
'info share' should do part of it... winedbg doesn't show the command line info nor options
That only shows me the memory ranges of some modules. The minidump includes more info, like the paths to dlls and similar. I am not sure whether it includes version information, but it certainly contains the commandline used to start the app.
other thing you can do is to use winedump (man winedump)
How do I do this? And what will it provide? I tried winedump -G warzone2100.exe but I have no idea what I shall do with that tremedously long and cryptic list.
- How can I get the parameters to the last called function(s)?
see above for debug info
If the general debug info worked, that would also show me the function parameters?
--Dennis
2007/3/29, Dennis Schridde devurandom@gmx.net:
Am Donnerstag, 29. März 2007 schrieb Eric Pouech:
Dennis Schridde a écrit :
Hello Wine users!
I've got a minidump from a ("real") Windows user of our game and would like to extract information from it using winedbg.
The information winedbg gives me by default, is this:
[...]
Which is pretty rare. Via addr2line I can translate the backtrace to possibly valid
locations
in our sourcefiles.
My questions are:
- Why doesn't winedbg extract the sourcecode locations itself?
because it needs the original PE files (.exe, .dll) to get to the debug information those files must be seated in directories listed in the _NT_SYMBOL_PATH environment variable
Maybe I am just doing it wrong, but _NT_SYMBOL_PATH=. winedbg warzone2100.mdmp doesn't change anything... (Even supplying the full path doesn't.) The exe (not all dlls, because I don't have a copy of the user's system) is of course in the working directory.
But the debug info is not always in the .exe itself. the .exe can contain only a pointer to the debug info what does 'winedbg -x debug -g warzone2100.exe' give ?
- Why doesn't winedbg show me the other information included in the
minidump, like the loaded modules, commandline options or version information?
'info share' should do part of it... winedbg doesn't show the command line info nor options
That only shows me the memory ranges of some modules. The minidump includes more info, like the paths to dlls and similar. I am not sure whether it includes version information, but it certainly contains the commandline used to start the app.
other thing you can do is to use winedump (man winedump)
How do I do this? And what will it provide? I tried winedump -G warzone2100.exe but I have no idea what I shall do with that tremedously long and cryptic list.
winedump warzone2100.mdmp
- How can I get the parameters to the last called function(s)?
see above for debug info
If the general debug info worked, that would also show me the function parameters?
yes
Am Freitag, 30. März 2007 schrieb Eric Pouech:
2007/3/29, Dennis Schridde devurandom@gmx.net:
Am Donnerstag, 29. März 2007 schrieb Eric Pouech:
Dennis Schridde a écrit :
Hello Wine users!
I've got a minidump from a ("real") Windows user of our game and would like to extract information from it using winedbg.
The information winedbg gives me by default, is this:
[...]
Which is pretty rare. Via addr2line I can translate the backtrace to possibly valid
locations
in our sourcefiles.
My questions are:
- Why doesn't winedbg extract the sourcecode locations itself?
because it needs the original PE files (.exe, .dll) to get to the debug information those files must be seated in directories listed in the _NT_SYMBOL_PATH environment variable
Maybe I am just doing it wrong, but _NT_SYMBOL_PATH=. winedbg warzone2100.mdmp doesn't change anything... (Even supplying the full path doesn't.) The exe (not all dlls, because I don't have a copy of the user's system) is of course in the working directory.
But the debug info is not always in the .exe itself. the .exe can contain only a pointer to the debug info
This exe was compiled using the GCC switch "-g" and was not striped afterwards, it is ~10MB big (the usual size of our app when compiled in debug mode) and winedump drops a long list of I don't know what when I run "winedump -G warzone2100.exe".
what does 'winedbg -x debug -g warzone2100.exe' give ?
Usage information...
winedbg has neither a -x nor a -g parameter. winedump has a -x parameter (which takes no option) and a -G parameter. It complains about not being able to treat multiple files. So you probably meant a completely different tool...
- Why doesn't winedbg show me the other information included in the
minidump, like the loaded modules, commandline options or version information?
'info share' should do part of it... winedbg doesn't show the command line info nor options
That only shows me the memory ranges of some modules. The minidump includes more info, like the paths to dlls and similar. I am not sure whether it includes version information, but it certainly contains the commandline used to start the app.
other thing you can do is to use winedump (man winedump)
How do I do this? And what will it provide? I tried winedump -G warzone2100.exe but I have no idea what I shall do with that tremedously long and cryptic list.
winedump warzone2100.mdmp
This is actually useful. Things like file versions, modules and so on are printed. What's still missing (and only visible in the binary listing of "Memory ranges" is the commandline. Are there plans to make this info accessible from winedbg? Or to include things like backtrace information into winedump?
--Dennis
Dennis Schridde a écrit :
Am Freitag, 30. März 2007 schrieb Eric Pouech:
2007/3/29, Dennis Schridde devurandom@gmx.net:
Am Donnerstag, 29. März 2007 schrieb Eric Pouech:
Dennis Schridde a écrit :
Hello Wine users!
I've got a minidump from a ("real") Windows user of our game and would like to extract information from it using winedbg.
The information winedbg gives me by default, is this:
[...]
Which is pretty rare. Via addr2line I can translate the backtrace to possibly valid
locations
in our sourcefiles.
My questions are:
- Why doesn't winedbg extract the sourcecode locations itself?
because it needs the original PE files (.exe, .dll) to get to the debug information those files must be seated in directories listed in the _NT_SYMBOL_PATH environment variable
Maybe I am just doing it wrong, but _NT_SYMBOL_PATH=. winedbg warzone2100.mdmp doesn't change anything... (Even supplying the full path doesn't.) The exe (not all dlls, because I don't have a copy of the user's system) is of course in the working directory.
But the debug info is not always in the .exe itself. the .exe can contain only a pointer to the debug info
This exe was compiled using the GCC switch "-g" and was not striped afterwards, it is ~10MB big (the usual size of our app when compiled in debug mode) and winedump drops a long list of I don't know what when I run "winedump -G warzone2100.exe".
what does 'winedbg -x debug -g warzone2100.exe' give ?
Usage information...
winedbg has neither a -x nor a -g parameter. winedump has a -x parameter (which takes no option) and a -G parameter. It complains about not being able to treat multiple files. So you probably meant a completely different tool...
I actually meant winedump dump -x debug -G warzone2100.exe
- Why doesn't winedbg show me the other information included in the
minidump, like the loaded modules, commandline options or version information?
'info share' should do part of it... winedbg doesn't show the command line info nor options
That only shows me the memory ranges of some modules. The minidump includes more info, like the paths to dlls and similar. I am not sure whether it includes version information, but it certainly contains the commandline used to start the app.
other thing you can do is to use winedump (man winedump)
How do I do this? And what will it provide? I tried winedump -G warzone2100.exe but I have no idea what I shall do with that tremedously long and cryptic list.
winedump warzone2100.mdmp
This is actually useful. Things like file versions, modules and so on are printed. What's still missing (and only visible in the binary listing of "Memory ranges" is the commandline. Are there plans to make this info accessible from winedbg? Or to include things like backtrace information into winedump?
the backtrace will be visibel in winedbg the command line will not be available, as it's not store (as a command line) in the minidump it's present because the minidump contains stack fragments, and the command occurs to be on the stack, but there's no easy way to link the two
can you directly send me your .mdmp and .exe file so I can have a look at the details
--Dennis
Am Samstag, 31. März 2007 schrieb Eric Pouech:
what does 'winedbg -x debug -g warzone2100.exe' give ?
Usage information...
winedbg has neither a -x nor a -g parameter. winedump has a -x parameter (which takes no option) and a -G parameter. It complains about not being able to treat multiple files. So you probably meant a completely different tool...
I actually meant winedump dump -x debug -G warzone2100.exe
Still does not work... "Only one file can be treated at once"
--Dennis
"Dennis Schridde" devurandom@gmx.net wrote:
I actually meant winedump dump -x debug -G warzone2100.exe
Still does not work... "Only one file can be treated at once"
'winedump dump -j debug -G warzone2100.exe' should work.