I'm trying to debug a program that page faults on me, and I'm actually
quite keen to have a go at fixing it myself.
Unfortunately, I seem to have fallen at the first hurdle: I can't make
good use of the debug messages.
Background:
The program I am attempting to run is TrackLogs
( http://www.tracklogs.co.uk ). Installation went fine and on first run
I got the licence key dialogue, which I filled and it was after that It
crashed. On restart, it prompts me to accept that I have so many days
left on the licence, and then it crashes as I continue. Attached are the
various dubugging dumps (so I get a single dialogue screen before the
crash).
Debugging:
If I set the windows version (within winecfg) to XP or 2000, I end up
getting the same calls repeated as long as I can be bothered to wait.
Running "WINEDEBUG=+relay wine TrackLogsV3.exe" I get the following
calls repeated:
0009:Call KERNEL32.TlsGetValue(00000001) ret=7c34964c
0009:Ret KERNEL32.TlsGetValue() retval=00db00f8 ret=7c34964c
0009:Call KERNEL32.SetLastError(0000007a) ret=7c3496a2
0009:Ret KERNEL32.SetLastError() retval=0000007a ret=7c3496a2
0009:Call KERNEL32.GetLastError() ret=7c34963e
0009:Ret KERNEL32.GetLastError() retval=0000007a ret=7c34963e
and then it repeats exactly. This is after a fairly sensible looking
initialisation.
If I set the windows version to 98, I get as the final few lines:
0009:Call
ntdll.NtWaitForMultipleObjects(00000001,0034db50,00000000,00000000,00000000)
ret=7b8881c6
0009:Ret ntdll.NtWaitForMultipleObjects() retval=00000000 ret=7b8881c6
0009:Call ntdll.RtlFreeHeap(00110000,00000000,001b45d8) ret=7b84f22b
0009:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7b84f22b
0009:Ret KERNEL32.UnhandledExceptionFilter() retval=00000000
ret=7c34c456
0009:Call
ntdll.NtQueryVirtualMemory(ffffffff,003b2000,00000000,0034dfc8,0000001c,0034dcec)
ret=7b897aa1
0009:Ret ntdll.NtQueryVirtualMemory() retval=00000000 ret=7b897aa1
Unhandled exception: page fault on write access to 0x003b2000 in 32-bit
code (0x678ead31).
I'd appreciate any pointers on how to proceed from here.
Thanks and regards,
Henry
-------------- next part --------------
wine: Unhandled page fault on write access to 0x035b2000 at address 0x678ead31
(thread 0009), starting debugger...
Unhandled exception: page fault on write access to 0x035b2000 in 32-bit code
(0x678ead31).
Register dump:
CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b
EIP:678ead31 ESP:0034e850 EBP:0034e8c0 EFLAGS:00210287( - 00 RISP1C)
EAX:00000000 EBX:66666666 ECX:00000020 EDX:01b94f00
ESI:01b683a0 EDI:035b2000
Stack dump:
0x0034e850: 01b68370 0000000a 01b43aa0 00000028
0x0034e860: 000001e0 00000030 00180001 00000000
0x0034e870: 00010e00 00000000 00000000 00000000
0x0034e880: 00000000 00000000 7c173da4 00006724
0x0034e890: 00006724 00000000 00000000 00000000
0x0034e8a0: 7c3416db 00000001 01b808e8 01b81380
Backtrace:
=>1 0x678ead31 in xtp9601lib (+0xead31) (0x0034e8c0)
2 0x678ed5ec in xtp9601lib (+0xed5ec) (0x0034e94c)
3 0x00006720 (0x6791ce24)
4 0x67819340 in xtp9601lib (+0x19340) (0x6790afb8)
0x678ead31: movl %ebx,0x0(%edi)
Modules:
Module Address Debug info Name (103 modules)
PE 400000- da7000 Deferred tracklogsv3
PE 67800000-67a11000 Export xtp9601lib
PE 69b10000-69c3f000 Deferred msxml4
ELF 7b800000-7b927000 Deferred kernel32<elf>
\-PE 7b820000-7b927000 \ kernel32
ELF 7bc00000-7bc97000 Deferred ntdll<elf>
\-PE 7bc10000-7bc97000 \ ntdll
ELF 7bf00000-7bf03000 Deferred <wine-loader>
PE 7c140000-7c243000 Deferred mfc71
PE 7c340000-7c396000 Deferred msvcr71
ELF 7c69c000-7c6b0000 Deferred shfolder<elf>
\-PE 7c6a0000-7c6b0000 \ shfolder
ELF 7c6b0000-7c6c4000 Deferred msimg32<elf>
\-PE 7c6c0000-7c6c4000 \ msimg32
ELF 7c6c4000-7c6d9000 Deferred midimap<elf>
\-PE 7c6d0000-7c6d9000 \ midimap
ELF 7c6d9000-7c6f1000 Deferred msacm32<elf>
\-PE 7c6e0000-7c6f1000 \ msacm32
ELF 7c6f1000-7c7b6000 Deferred libasound.so.2
ELF 7c7b6000-7c7e7000 Deferred winealsa<elf>
\-PE 7c7c0000-7c7e7000 \ winealsa
ELF 7cf54000-7d8b5000 Deferred fglrx_dri.so
ELF 7d9bd000-7d9ef000 Deferred uxtheme<elf>
\-PE 7d9c0000-7d9ef000 \ uxtheme
ELF 7da6a000-7da6f000 Deferred libxfixes.so.3
ELF 7da6f000-7da8c000 Deferred imm32<elf>
\-PE 7da80000-7da8c000 \ imm32
ELF 7dcb9000-7dcc2000 Deferred libxcursor.so.1
ELF 7dcc2000-7dcca000 Deferred libxrender.so.1
ELF 7dfba000-7dfc3000 Deferred librt.so.1
ELF 7dfc4000-7dfca000 Deferred libxrandr.so.2
ELF 7dfca000-7dfcd000 Deferred libxinerama.so
ELF 7e090000-7e11f000 Deferred winex11<elf>
\-PE 7e0a0000-7e11f000 \ winex11
ELF 7e1b8000-7e1d8000 Deferred libexpat.so.1
ELF 7e1d8000-7e203000 Deferred libfontconfig.so.1
ELF 7e203000-7e217000 Deferred libz.so.1
ELF 7e217000-7e282000 Deferred libfreetype.so.6
ELF 7e282000-7e2a1000 Deferred mpr<elf>
\-PE 7e290000-7e2a1000 \ mpr
ELF 7e2a1000-7e2ce000 Deferred ws2_32<elf>
\-PE 7e2b0000-7e2ce000 \ ws2_32
ELF 7e2ce000-7e2f3000 Deferred netapi32<elf>
\-PE 7e2e0000-7e2f3000 \ netapi32
ELF 7e2f3000-7e319000 Deferred msacm32<elf>
\-PE 7e300000-7e319000 \ msacm32
ELF 7e319000-7e353000 Deferred avifil32<elf>
\-PE 7e320000-7e353000 \ avifil32
ELF 7e353000-7e37a000 Deferred msvfw32<elf>
\-PE 7e360000-7e37a000 \ msvfw32
ELF 7e37a000-7e409000 Deferred winmm<elf>
\-PE 7e390000-7e409000 \ winmm
ELF 7e409000-7e4a4000 Deferred oleaut32<elf>
\-PE 7e420000-7e4a4000 \ oleaut32
ELF 7e4a4000-7e541000 Deferred ole32<elf>
\-PE 7e4b0000-7e541000 \ ole32
ELF 7e541000-7e5fd000 Deferred comctl32<elf>
\-PE 7e550000-7e5fd000 \ comctl32
ELF 7e5fd000-7e6f8000 Deferred shell32<elf>
\-PE 7e610000-7e6f8000 \ shell32
ELF 7e6f8000-7e750000 Deferred shlwapi<elf>
\-PE 7e710000-7e750000 \ shlwapi
ELF 7e750000-7e763000 Deferred libresolv.so.2
ELF 7e763000-7e781000 Deferred iphlpapi<elf>
\-PE 7e770000-7e781000 \ iphlpapi
ELF 7e781000-7e7d6000 Deferred rpcrt4<elf>
\-PE 7e790000-7e7d6000 \ rpcrt4
ELF 7e7d6000-7e7ea000 Deferred lz32<elf>
\-PE 7e7e0000-7e7ea000 \ lz32
ELF 7e7ea000-7e803000 Deferred version<elf>
\-PE 7e7f0000-7e803000 \ version
ELF 7e803000-7e861000 Deferred setupapi<elf>
\-PE 7e810000-7e861000 \ setupapi
ELF 7e861000-7e877000 Deferred glu32<elf>
\-PE 7e870000-7e877000 \ glu32
ELF 7e877000-7e8be000 Deferred advapi32<elf>
\-PE 7e880000-7e8be000 \ advapi32
ELF 7e8be000-7e97d000 Deferred gdi32<elf>
\-PE 7e8e0000-7e97d000 \ gdi32
ELF 7e97d000-7eab9000 Deferred user32<elf>
\-PE 7e9a0000-7eab9000 \ user32
ELF 7eab9000-7eac5000 Deferred libgcc_s.so.1
ELF 7ebc2000-7ebc7000 Deferred libxdmcp.so.6
ELF 7ebc7000-7ec47000 Deferred libglu.so.1
ELF 7ec47000-7ece7000 Deferred libgl.so.1
ELF 7ece7000-7edd8000 Deferred libx11.so.6
ELF 7edd8000-7ede6000 Deferred libxext.so.6
ELF 7ede6000-7edfe000 Deferred libice.so.6
ELF 7edfe000-7ee07000 Deferred libsm.so.6
ELF 7ee07000-7ee88000 Deferred opengl32<elf>
\-PE 7ee20000-7ee88000 \ opengl32
ELF 7ef9a000-7efa5000 Deferred libnss_files.so.2
ELF 7efa5000-7efaf000 Deferred libnss_nis.so.2
ELF 7efaf000-7efc6000 Deferred libnsl.so.1
ELF 7efc6000-7efed000 Deferred libm.so.6
ELF 7efef000-7eff2000 Deferred libxau.so.6
ELF b7ca1000-b7ca6000 Deferred libxxf86vm.so.1
ELF b7ca6000-b7caf000 Deferred libnss_compat.so.2
ELF b7cb0000-b7cb4000 Deferred libdl.so.2
ELF b7cb4000-b7df5000 Deferred libc.so.6
ELF b7df6000-b7e0d000 Deferred libpthread.so.0
ELF b7e20000-b7f31000 Deferred libwine.so.1
ELF b7f33000-b7f4e000 Deferred ld-linux.so.2
Threads:
process tid prio (all id:s are in hex)
0000000a
0000000c 0
0000000b 0
00000008 (D) C:\Program Files\TrackLogs\TrackLogsV3.exe
00000009 0 <==
On Wed, 2007-05-23 at 11:37 +0100, Henry Gomersall wrote:> I'm trying to debug a program that page faults on me, and I'm actually > quite keen to have a go at fixing it myself. > > Unfortunately, I seem to have fallen at the first hurdle: I can't make > good use of the debug messages.[SNIP]> ntdll.NtQueryVirtualMemory(ffffffff,003b2000,00000000,0034dfc8,0000001c,0034dcec) ret=7b897aa1 > 0009:Ret ntdll.NtQueryVirtualMemory() retval=00000000 ret=7b897aa1 > Unhandled exception: page fault on write access to 0x003b2000 in 32-bit > code (0x678ead31). > > I'd appreciate any pointers on how to proceed from here.Try setting ntdll.dll as native in winecfg. Install a real one, and list it as native in winecfg/libraries -- Declan Moriarty <junk_mail@iol.ie>
Henry Gomersall wrote:> I'm trying to debug a program that page faults on me, and I'm actually > quite keen to have a go at fixing it myself. > > Unfortunately, I seem to have fallen at the first hurdle: I can't make > good use of the debug messages. > > Background: > The program I am attempting to run is TrackLogs > ( http://www.tracklogs.co.uk ). Installation went fine and on first run > I got the licence key dialogue, which I filled and it was after that It > crashed. On restart, it prompts me to accept that I have so many days > left on the licence, and then it crashes as I continue. Attached are the > various dubugging dumps (so I get a single dialogue screen before the > crash). > > Debugging: > If I set the windows version (within winecfg) to XP or 2000, I end up > getting the same calls repeated as long as I can be bothered to wait. > Running "WINEDEBUG=+relay wine TrackLogsV3.exe"...You mean you are letting the messages print to your terminal? That will likely slow things down too much to be useful. Better to redirect to a file: WINEDEBUG=+relay wine TrackLogsV3.exe &> wine.log That will still be slower than without debugging, but should be fast enough to be useful. The file can sometimes be vary large (>1GB) though since it apparently is failing early, probably it will not be so big. After the log is written to a file, I generally find it easier to chop into pieces: split --bytes=20m wine.log That will create files named xaa, xab ... If you are going through the relay traces, there is a tool in the wine tree that makes them easier to read (at least for me): wine/tools/examine-relay xaa -f > xaa2 Now the file xaa2 will have the relay traces nicely indented.> I get the following > calls repeated: > 0009:Call KERNEL32.TlsGetValue(00000001) ret=7c34964c > 0009:Ret KERNEL32.TlsGetValue() retval=00db00f8 ret=7c34964c > 0009:Call KERNEL32.SetLastError(0000007a) ret=7c3496a2 > 0009:Ret KERNEL32.SetLastError() retval=0000007a ret=7c3496a2 > 0009:Call KERNEL32.GetLastError() ret=7c34963e > 0009:Ret KERNEL32.GetLastError() retval=0000007a ret=7c34963eIn your ~/.wine/user.reg, there is a registry key: [Software\\Wine\\Debug] 1147111116 "RelayExclude"="ntdll.RtlEnterCriticalSection;ntdll.RtlLeaveCriticalSection;kernel32.97;kernel32.98" Try adding kernel32.TlsGetValue etc to it.> If I set the windows version to 98, I get as the final few lines:Does the program run under Win98? In any case, I wouldn't bother trying to run it that way.
On Thu, 2007-05-24 at 11:52 -0700, Duane Clark wrote:> Well, those are not the actual last few lines before the crash, > because > I see a return from KERNEL32.UnhandledExceptionFilter() without the > call. I think the program actually crashed somewhere before the call > to > that function. I often grep through the log for "xception" (without > "E"/"e" so that case does not matter) to find the first place in the > log > where that word shows up.Well, I have several of these in the relay log. The following snippets show the ones before the crash: Ok [0009]: ntdll.NtClose from 7b87cf8e with none. Ok [0009]: ntdll.NtAllocateVirtualMemory from 7b8977a7 with none. Ok [0009]: ntdll.RtlAddVectoredExceptionHandler from 7b8407ed with none. -- Ok [000b]: ntdll.NtClose from 7b87cf8e with none. Ok [000b]: ntdll.NtAllocateVirtualMemory from 7b8977a7 with none. Ok [000b]: ntdll.RtlAddVectoredExceptionHandler from 7b8407ed with none. -- Ok [0009]: ntdll.NtQuerySystemTime from 7b893f25 with none. Ok [0009]: KERNEL32.GetSystemTimeAsFileTime from 7c34207b with none. Ok [0009]: KERNEL32.SetUnhandledExceptionFilter from 7c3411b1 with none. -- Ok [0009]: ntdll.RtlInitializeCriticalSection from 7b887e8d with none. Ok [0009]: KERNEL32.InitializeCriticalSection from 7e0c7349 with none. Ok [0009]: ntdll.RtlAddVectoredExceptionHandler from 7e0c7433 with none. -- Ok [0009]: ntdll.RtlFreeUnicodeString from 7b875493 with none. Ok [0009]: ntdll.NtWaitForMultipleObjects from 7b8881c6 with none. Ok [0009]: KERNEL32.UnhandledExceptionFilter from 7c34c456 with none. Ok [0009]: ntdll.NtQueryVirtualMemory from 7b897aa1 with none. Unhandled exception: page fault on write access to 0x035b2000 in 32-bit code (0x678ead31). -- Running the debugger I can get each of the above exceptions to show (by pressing c on in the debug console). However, I still cannot work out where to discover which function is actually giving the error. The backtrace refers to the library xtp9601lib, which is a dll included with the program (and the function that originates the page fault is in this address range - at least that is my interpretation). I presume I should be able to, in principle, find the offending function call? Thanks, Henry
Henry Gomersall wrote:> > Well, I have several of these in the relay log. The following snippets > show the ones before the crash: > > Ok [0009]: ntdll.NtClose from 7b87cf8e with none. > Ok [0009]: ntdll.NtAllocateVirtualMemory from 7b8977a7 with none. > Ok [0009]: ntdll.RtlAddVectoredExceptionHandler from 7b8407ed with > none.Adding exception handlers is uninteresting.> ... > Ok [0009]: KERNEL32.UnhandledExceptionFilter from > 7c34c456 with none.That is the actual place where an exception was caught. I typically check what a function does by going to http://msdn2.microsoft.com/en-us/library/default.aspx and plugging the function name into the search box.> > Running the debugger I can get each of the above exceptions to show (by > pressing c on in the debug console). However, I still cannot work out > where to discover which function is actually giving the error. The > backtrace refers to the library xtp9601lib, which is a dll included with > the program (and the function that originates the page fault is in this > address range - at least that is my interpretation). > > I presume I should be able to, in principle, find the offending function > call?Maybe ;) It is a bit of a black art and one that I am not particularly good at. In this case, go through the relay trace prior to that UnhandledExceptionFilter call, and see if you can figure out what was happening. Or post a hundred lines or so of the relay trace prior to that call.
Henry Gomersall wrote:> > Ok [0009]: ntdll.NtClose from 7b87cf8e with none. > Ok [0009]: ntdll.NtAllocateVirtualMemory from 7b8977a7 with none. > Ok [0009]: ntdll.RtlAddVectoredExceptionHandler from 7b8407ed with > none.By the way, the reason this is formatted differently from the previous posting is that you did not add a "-f" flag to the end of the examine-relay command. The flag alters how the output is formatted.