1.1.1. Processes and threads: in underlying OS and in Windows

Before going into the depths of debugging in Wine, here's a small overview of process and thread handling in Wine. It has to be clear that there are two different beasts: processes/threads from the Unix point of view and processes/threads from a Windows point of view.

Each Windows' thread is implemented as a Unix thread, meaning that all threads of a same Windows' process share the same (unix) address space.

In the following:

• W-process means a process in Windows' terminology

• U-process means a process in Unix' terminology

• W-thread means a thread in Windows' terminology

A W-process is made of one or several W-threads. Each W-thread is mapped to one and only one U-process. All U-processes of a same W-process share the same address space.

Each Unix process can be identified by two values:

• the Unix process id (upid in the following)

• the Windows's thread id (tid)

Each Windows' process has also a Windows' process id (wpid in the following). It must be clear that upid and wpid are different and shall not be used instead of the other.

Wpid and tid are defined (Windows) system wide. They must not be confused with process or thread handles which, as any handle, is an indirection to a system object (in this case process or thread). A same process can have several different handles on the same kernel object. The handles can be defined as local (the values is only valid in a process), or system wide (the same handle can be used by any W-process).

1.1.2. Wine, debugging and WineDbg

When talking of debugging in Wine, there are at least two levels to think of:

• the Windows' debugging API.

• the Wine integrated debugger, dubbed winedbg.

Wine implements most of the Windows' debugging API. The first part of the debugging APIs (in KERNEL32.DLL) allows a W-process, called the debugger, to control the execution of another W-process, the debuggee. To control means stopping/resuming execution, enabling/disabling single stepping, setting breakpoints, reading/writing debuggee memory... Another part of the debugging APIs resides in DBGHELP.DLL (and its ancestor IMAGEHLP.DLL) and lets a debugger look into symbols and types from any module (if the module has been compiled with the proper options).

winedbg is a Winelib application making use of these APIs (KERNEL32.DLL's debugging API and DBGHELP.DLL) to allow debugging both any Wine or Winelib applications as well as Wine itself (kernel and all DLLs).

1.2.1. Starting a process

Any application (either a Windows' native executable, or a Winelib application) can be run through winedbg. Command line options and tricks are the same as for wine:

winedbg telnet.exe
winedbg hl.exe -windowed
        

1.2.2. Attaching

winedbg can also be launched without any command line argument: winedbg is started without any attached process. You can get a list of running W-processes (and their wpid's) using the info process command, and then, with the attach command, pick up the wpid of the W-process you want to debug. This is a neat feature as it allows you to debug an already started application.

1.2.3. On exceptions

When something goes wrong, Windows tracks this as an exception. Exceptions exist for segmentation violation, stack overflow, division by zero, etc.

When an exception occurs, Wine checks if the W-process is debugged. If so, the exception event is sent to the debugger, which takes care of it: end of the story. This mechanism is part of the standard Windows' debugging API.

If the W-process is not debugged, Wine tries to launch a debugger. This debugger (normally winedbg, see III Configuration for more details), at startup, attaches to the W-process which generated the exception event. In this case, you are able to look at the causes of the exception, and either fix the causes (and continue further the execution) or dig deeper to understand what went wrong.

If winedbg is the standard debugger, the pass and cont commands are the two ways to let the process go further for the handling of the exception event.

To be more precise on the way Wine (and Windows) generates exception events, when a fault occurs (segmentation violation, stack overflow...), the event is first sent to the debugger (this is known as a first chance exception). The debugger can give two answers:

1.2.4. Interrupting

You can stop the debugger while it's running by hitting Ctrl-C in its window. This will stop the debugged process, and let you manipulate the current context.

1.2.5. Quitting

Wine supports the new XP APIs, allowing for a debugger to detach from a program being debugged (see detach command).

1.3.1. Crashes

These usually show up like this:

|Unexpected Windows program segfault - opcode = 8b
|Segmentation fault in Windows program 1b7:c41.
|Loading symbols from ELF file /root/wine/wine...
|....more Loading symbols from ...
|In 16 bit mode.
|Register dump:
| CS:01b7 SS:016f DS:0287 ES:0000
| IP:0c41 SP:878a BP:8796 FLAGS:0246
| AX:811e BX:0000 CX:0000 DX:0000 SI:0001 DI:ffff
|Stack dump:
|0x016f:0x878a:  0001 016f ffed 0000 0000 0287 890b 1e5b
|0x016f:0x879a:  01b7 0001 000d 1050 08b7 016f 0001 000d
|0x016f:0x87aa:  000a 0003 0004 0000 0007 0007 0190 0000
|0x016f:0x87ba:
|
|0050: sel=0287 base=40211d30 limit=0b93f (bytes) 16-bit rw-
|Backtrace:
|0 0x01b7:0x0c41 (PXSRV_FONGETFACENAME+0x7c)
|1 0x01b7:0x1e5b (PXSRV_FONPUTCATFONT+0x2cd)
|2 0x01a7:0x05aa
|3 0x01b7:0x0768 (PXSRV_FONINITFONTS+0x81)
|4 0x014f:0x03ed (PDOXWIN_@SQLCURCB$Q6CBTYPEULN8CBSCTYPE+0x1b1)
|5 0x013f:0x00ac
|
|0x01b7:0x0c41 (PXSRV_FONGETFACENAME+0x7c):  movw        %es:0x38(%bx),%dx
        

Steps to debug a crash. You may stop at any step, but please report the bug and provide as much of the information gathered to the bug report as feasible.

1. Get the reason for the crash. This is usually an access to an invalid selector, an access to an out of range address in a valid selector, popping a segment register from the stack or the like. When reporting a crash, report this whole crashdump even if it doesn't make sense to you.

   (In this case it is access to an invalid selector, for %es is 0000, as seen in the register dump).

2. Determine the cause of the crash. Since this is usually a primary/secondary reaction to a failed or misbehaving Wine function, rerun Wine with the WINEDEBUG=+relay environment variable set. This will generate quite a lot of output, but usually the reason is located in the last call(s). Those lines usually look like this:

   |Call KERNEL.90: LSTRLEN(0227:0692 "text") ret=01e7:2ce7 ds=0227
         ^^^^^^^^^  ^       ^^^^^^^^^ ^^^^^^      ^^^^^^^^^    ^^^^
         |          |       |         |           |            |Datasegment
         |          |       |         |           |Return address
         |          |       |         |textual parameter
         |          |       |
         |          |       |Argument(s).  This one is a win16 segmented pointer.
         |          |Function called.
         |The module, the function is called in.  In this case it is KERNEL.
   
   |Ret  KERNEL.90: LSTRLEN() retval=0x0004 ret=01e7:2ce7 ds=0227
                                     ^^^^^^
   				  |Returnvalue is 16 bit and has the value 4.
               

3. If you have found a misbehaving Wine function, try to find out why it misbehaves. Find the function in the source code. Try to make sense of the arguments passed. Usually there is a WINE_DEFAULT_DEBUG_CHANNEL(<channel>); at the beginning of the source file. Rerun wine with the WINEDEBUG=+xyz,+relay environment variable set.

   Occasionally there are additional debug channels defined at the beginning of the source file in the form WINE_DECLARE_DEBUG_CHANNEL(<channel>); If so the offending function may also uses one of these alternate channels. Look through the the function for TRACE_(<channel>)(" ... /n"); and add any additional channels to the commandline.

4. Additional information on how to debug using the internal debugger can be found in programs/winedbg/README.

5. If this information isn't clear enough or if you want to know more about what's happening in the function itself, try running wine with WINEDEBUG=+all, which dumps ALL included debug information in wine. It is often necessary to limit the debug output produced. That can be done by piping the output through grep, or alternatively with registry keys. See Section 1.5.3 for more information.

6. If even that isn't enough, add more debug output for yourself into the functions you find relevant. See The section on Debug Logging in this guide for more information. You might also try to run the program in gdb instead of using the Wine debugger. If you do that, use handle SIGSEGV nostop noprint to disable the handling of seg faults inside gdb (needed for Win16).

7. You can also set a breakpoint for that function. Start wine using winedbg instead of wine. Once the debugger is running enter break KERNEL_LSTRLEN (replace by function you want to debug, CASE IS RELEVANT) to set a breakpoint. Then use continue to start normal program-execution. Wine will stop if it reaches the breakpoint. If the program isn't yet at the crashing call of that function, use continue again until you are about to enter that function. You may now proceed with single-stepping the function until you reach the point of crash. Use the other debugger commands to print registers and the like.

1.3.2. Program hangs, nothing happens

Start the program with winedbg instead of wine. When the program locks up switch to the winedbg's terminal and press Ctrl-C. This will stop the program and let you debug the program as you would for a crash.

1.3.3. Program reports an error with a Messagebox

Sometimes programs are reporting failure using more or less nondescript messageboxes. We can debug this using the same method as Crashes, but there is one problem... For setting up a message box the program also calls Wine producing huge chunks of debug code.

Since the failure happens usually directly before setting up the Messagebox you can start winedbg and set a breakpoint at MessageBoxA (called by win16 and win32 programs) and proceed with continue. With WINEDEBUG=+all Wine will now stop directly before setting up the Messagebox. Proceed as explained above.

You can also run wine using WINEDEBUG=+relay wine program.exe 2>&1 | less -i and in less search for "MessageBox".

1.3.4. Disassembling programs

You may also try to disassemble the offending program to check for undocumented features and/or use of them.

The best, freely available, disassembler for Win16 programs is Windows Codeback, archive name wcbxxx.zip (e.g. wcb105a.zip).

Disassembling win32 programs is possible using eg. GoVest by Ansgar Trimborn. It can be found here.

You can also use the newer and better Interactive Disassembler (IDA) from DataRescue. Take a look in the AppDB for links to various versions of IDA.

Another popular disassembler is Windows Disassembler 32 from URSoft. Look for a file called w32dsm87.zip (or similar) on winsite.com or softpedia.com. It seems that Windows Disassembler 32 currently has problems working correctly under Wine, so use IDA or GoVest.

Also of considerable fame amongst disassemblers is SoftIce from NuMega. That software has since been acquired by CompuWare (http://www.compuware.com/) and made part of their Windows driver development suite. Newer versions of SoftIce needs to run as a Windows Service and therefore won't currently work under Wine.

If nothing works for you, you might try one of the disassemblers found in Google's directory.

Understanding disassembled code is mostly a question of exercise. Most code out there uses standard C function entries (for it is usually written in C). Win16 function entries usually look like that:

push bp
mov bp, sp
... function code ..
retf XXXX 	<--------- XXXX is number of bytes of arguments
        

This is a FAR function with no local storage. The arguments usually start at [bp+6] with increasing offsets. Note, that [bp+6] belongs to the rightmost argument, for exported win16 functions use the PASCAL calling convention. So, if we use strcmp(a,b) with a and b both 32 bit variables b would be at [bp+6] and a at [bp+10].

Most functions make also use of local storage in the stackframe:

enter 0086, 00
... function code ...
leave
retf XXXX
        

This does mostly the same as above, but also adds 0x86 bytes of stackstorage, which is accessed using [bp-xx]. Before calling a function, arguments are pushed on the stack using something like this:

push word ptr [bp-02]	<- will be at [bp+8]
push di			<- will be at [bp+6]
call KERNEL.LSTRLEN
        

Here first the selector and then the offset to the passed string are pushed.

1.3.5. Sample debugging session

Let's debug the infamous Word SHARE.EXE messagebox:

|marcus@jet $ wine winword.exe
|            +---------------------------------------------+
|            | !  You must leave Windows and load SHARE.EXE|
|            |    before starting Word.                    |
|            +---------------------------------------------+
        

|marcus@jet $ WINEDEBUG=+relay,-debug wine winword.exe
|CallTo32(wndproc=0x40065bc0,hwnd=000001ac,msg=00000081,wp=00000000,lp=00000000)
|Win16 task 'winword': Breakpoint 1 at 0x01d7:0x001a
|CallTo16(func=0127:0070,ds=0927)
|Call WPROCS.24: TASK_RESCHEDULE() ret=00b7:1456 ds=0927
|Ret  WPROCS.24: TASK_RESCHEDULE() retval=0x8672 ret=00b7:1456 ds=0927
|CallTo16(func=01d7:001a,ds=0927)
|     AX=0000 BX=3cb4 CX=1f40 DX=0000 SI=0000 DI=0927 BP=0000 ES=11f7
|Loading symbols: /home/marcus/wine/wine...
|Stopped on breakpoint 1 at 0x01d7:0x001a
|In 16 bit mode.
|Wine-dbg>break MessageBoxA                          <---- Set Breakpoint
|Breakpoint 2 at 0x40189100 (MessageBoxA [msgbox.c:190])
|Wine-dbg>c                                            <---- Continue
|Call KERNEL.91: INITTASK() ret=0157:0022 ds=08a7
|     AX=0000 BX=3cb4 CX=1f40 DX=0000 SI=0000 DI=08a7 ES=11d7 EFL=00000286
|CallTo16(func=090f:085c,ds=0dcf,0x0000,0x0000,0x0000,0x0000,0x0800,0x0000,0x0000,0x0dcf)
|...                                                   <----- Much debugoutput
|Call KERNEL.136: GETDRIVETYPE(0x0000) ret=060f:097b ds=0927
                               ^^^^^^ Drive 0 (A:)
|Ret  KERNEL.136: GETDRIVETYPE() retval=0x0002 ret=060f:097b ds=0927
                                        ^^^^^^  DRIVE_REMOVEABLE
						(It is a floppy diskdrive.)

|Call KERNEL.136: GETDRIVETYPE(0x0001) ret=060f:097b ds=0927
                               ^^^^^^ Drive 1 (B:)
|Ret  KERNEL.136: GETDRIVETYPE() retval=0x0000 ret=060f:097b ds=0927
                                        ^^^^^^  DRIVE_CANNOTDETERMINE
						(I don't have drive B: assigned)

|Call KERNEL.136: GETDRIVETYPE(0x0002) ret=060f:097b ds=0927
                               ^^^^^^^ Drive 2 (C:)
|Ret  KERNEL.136: GETDRIVETYPE() retval=0x0003 ret=060f:097b ds=0927
                                        ^^^^^^ DRIVE_FIXED
                                               (specified as a harddisk)

|Call KERNEL.97: GETTEMPFILENAME(0x00c3,0x09278364"doc",0x0000,0927:8248) ret=060f:09b1 ds=0927
                                 ^^^^^^           ^^^^^        ^^^^^^^^^
                                 |                |            |buffer for fname
                                 |                |temporary name ~docXXXX.tmp
                                 |Force use of Drive C:.

|Warning: GetTempFileName returns 'C:~doc9281.tmp', which doesn't seem to be writable.
|Please check your configuration file if this generates a failure.
        

Whoops, it even detects that something is wrong!

|Ret  KERNEL.97: GETTEMPFILENAME() retval=0x9281 ret=060f:09b1 ds=0927
                                          ^^^^^^ Temporary storage ID

|Call KERNEL.74: OPENFILE(0x09278248"C:~doc9281.tmp",0927:82da,0x1012) ret=060f:09d8 ds=0927
                                    ^^^^^^^^^^^^^^^^ ^^^^^^^^^ ^^^^^^^
                                    |filename        |OFSTRUCT |open mode:

                                       OF_CREATE|OF_SHARE_EXCLUSIVE|OF_READWRITE
        

This fails, since my C: drive is in this case mounted readonly.

|Ret  KERNEL.74: OPENFILE() retval=0xffff ret=060f:09d8 ds=0927
                                   ^^^^^^ HFILE_ERROR16, yes, it failed.

|Call USER.1: MESSAGEBOX(0x0000,0x09278376"You must close Windows and load SHARE.EXE before you start Word.",0x00000000,0x1030) ret=060f:084f ds=0927
        

And MessageBox'ed.

|Stopped on breakpoint 2 at 0x40189100 (MessageBoxA [msgbox.c:190])
|190     {		<- the sourceline
In 32 bit mode.
Wine-dbg>
        

The code seems to find a writable harddisk and tries to create a file there. To work around this bug, you can define C: as a networkdrive, which is ignored by the code above.

1.3.6. Debugging Tips

Here are some additional debugging tips:

• If you have a program crashing at such an early loader phase that you can't use the Wine debugger normally, but Wine already executes the program's start code, then you may use a special trick. You should do a

  WINEDEBUG=+relay wine program
                

  to get a listing of the functions the program calls in its start function. Now you do a

  winedbg winfile.exe
                

  This way, you get into winedbg. Now you can set a breakpoint on any function the program calls in the start function and just type c to bypass the eventual calls of Winfile to this function until you are finally at the place where this function gets called by the crashing start function. Now you can proceed with your debugging as usual.

• If you try to run a program and it quits after showing an error messagebox, the problem can usually be identified in the return value of one of the functions executed before MessageBox(). That's why you should re-run the program with e.g.

  WINEDEBUG=+relay wine  <program name> &>relmsg
                

  Then do a more relmsg and search for the last occurrence of a call to the string "MESSAGEBOX". This is a line like

  Call USER.1: MESSAGEBOX(0x0000,0x01ff1246 "Runtime error 219 at 0004:1056.",0x00000000,0x1010) ret=01f7:2160 ds=01ff
                

  In my example the lines before the call to MessageBox() look like that:

  Call KERNEL.96: FREELIBRARY(0x0347) ret=01cf:1033 ds=01ff
  CallTo16(func=033f:0072,ds=01ff,0x0000)
  Ret  KERNEL.96: FREELIBRARY() retval=0x0001 ret=01cf:1033 ds=01ff
  Call KERNEL.96: FREELIBRARY(0x036f) ret=01cf:1043 ds=01ff
  CallTo16(func=0367:0072,ds=01ff,0x0000)
  Ret  KERNEL.96: FREELIBRARY() retval=0x0001 ret=01cf:1043 ds=01ff
  Call KERNEL.96: FREELIBRARY(0x031f) ret=01cf:105c ds=01ff
  CallTo16(func=0317:0072,ds=01ff,0x0000)
  Ret  KERNEL.96: FREELIBRARY() retval=0x0001 ret=01cf:105c ds=01ff
  Call USER.171: WINHELP(0x02ac,0x01ff05b4 "COMET.HLP",0x0002,0x00000000) ret=01cf:1070 ds=01ff
  CallTo16(func=0117:0080,ds=01ff)
  Call WPROCS.24: TASK_RESCHEDULE() ret=00a7:0a2d ds=002b
  Ret  WPROCS.24: TASK_RESCHEDULE() retval=0x0000 ret=00a7:0a2d ds=002b
  Ret  USER.171: WINHELP() retval=0x0001 ret=01cf:1070 ds=01ff
  Call KERNEL.96: FREELIBRARY(0x01be) ret=01df:3e29 ds=01ff
  Ret  KERNEL.96: FREELIBRARY() retval=0x0000 ret=01df:3e29 ds=01ff
  Call KERNEL.52: FREEPROCINSTANCE(0x02cf00ba) ret=01f7:1460 ds=01ff
  Ret  KERNEL.52: FREEPROCINSTANCE() retval=0x0001 ret=01f7:1460 ds=01ff
  Call USER.1: MESSAGEBOX(0x0000,0x01ff1246 "Runtime error 219 at 0004:1056.",0x00000000,0x1010) ret=01f7:2160 ds=01ff
                

  I think that the call to MessageBox() in this example is not caused by a wrong result value of some previously executed function (it's happening quite often like that), but instead the messagebox complains about a runtime error at 0x0004:0x1056.

  As the segment value of the address is only 4, I think that that is only an internal program value. But the offset address reveals something quite interesting: Offset 1056 is very close to the return address of FREELIBRARY():

  Call KERNEL.96: FREELIBRARY(0x031f) ret=01cf:105c ds=01ff
                                               ^^^^
                

  Provided that segment 0x0004 is indeed segment 0x1cf, we now we can use IDA to disassemble the part that caused the error. We just have to find the address of the call to FreeLibrary(). Some lines before that the runtime error occurred. But be careful! In some cases you don't have to disassemble the main program, but instead some DLL called by it in order to find the correct place where the runtime error occurred. That can be determined by finding the origin of the segment value (in this case 0x1cf).

• If you have created a relay file of some crashing program and want to set a breakpoint at a certain location which is not yet available as the program loads the breakpoint's segment during execution, you may set a breakpoint to GetVersion16/32 as those functions are called very often.

  Then do a c until you are able to set this breakpoint without error message.

1.3.7. Some basic debugger usages

After starting your program with

winedbg myprog.exe
        

the program loads and you get a prompt at the program starting point. Then you can set breakpoints:

  b RoutineName      (by routine name) OR
  b *0x812575        (by address)
        

Then you hit c (continue) to run the program. It stops at the breakpoint. You can type

  step               (to step one line) OR
  stepi              (to step one machine instruction at a time;
                      here, it helps to know the basic 386
                      instruction set)
  info reg           (to see registers)
  info stack         (to see hex values in the stack)
  info local         (to see local variables)
  list <line number> (to list source code)
  x <variable name>  (to examine a variable; only works if code
                      is not compiled with optimization)
  x 0x4269978        (to examine a memory location)
  ?                  (help)
  q                  (quit)
        

By hitting Enter, you repeat the last command.

1.3.8. Useful programs

Some useful programs:

1.5.1. Windows Debugging configuration

The Windows' debugging API uses a registry entry to know which debugger to invoke when an unhandled exception occurs (see On exceptions for some details). Two values in key

[MACHINE\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug]
        

Determine the behavior:

A regular Wine registry looks like:

[MACHINE\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug] 957636538
"Auto"=dword:00000001
"Debugger"="winedbg %ld %ld"
        

1.5.2. WineDbg configuration

winedbg can be configured through a number of options. Those options are stored in the registry, on a per user basis. The key is (in my registry)

[HKCU\\Software\\Wine\\WineDbg]
        

Those options can be read/written while inside winedbg, as part of the debugger expressions. To refer to one of these options, its name must be prefixed by a $ sign. For example,

set $BreakAllThreadsStartup = 1
        

sets the option BreakAllThreadsStartup to TRUE.

All the options are read from the registry when winedbg starts (if no corresponding value is found, a default value is used), and are written back to the registry when winedbg exits (hence, all modifications to those options are automatically saved when winedbg terminates).

Here's the list of all options:

1.5.3. Configuring +relay behaviour

When setting WINEDEBUG to +relay and debugging, you might get a lot of output. You can limit the output by configuring the value RelayExclude in the registry, located under the key:

          [HKCU\\Software\\Wine\\Debug]
        

Set the value of RelayExclude to a semicolon-separated list of calls to exclude. Example: "RtlEnterCriticalSection;RtlLeaveCriticalSection;kernel32.97;kernel32.98".

RelayInclude is an option similar to RelayExclude, except that functions listed here will be the only ones included in the output. Also see section 3.4.3.5 for more options.

If your application runs too slow with +relay to get meaningful output and you're stuck with multi-GB relay log files, but you're not sure what to exclude, here's a trick to get you started. First, run your application for a minute or so, piping it's output to a file on disk:

          WINEDEBUG=+relay wine <appname.exe> &>relay.log
        

Then run this command to see which calls are performed the most:

          awk -F'(' '{print $1}' < relay.log | awk '{print $2}' | sort | uniq -c | sort
        

Exclude the bottom-most calls with RelayExclude after making sure that they are irrelevant, then run your application again.

1.6.1. Expressions

Expressions in Wine Debugger are mostly written in a C form. However, there are a few discrepancies:

• Identifiers can take a '!' in their names. This allow mainly to access symbols from different DLLs like USER32!CreateWindowExA.

• In cast operation, when specifying a structure or an union, you must use the struct or union keyword (even if your program uses a typedef).

When specifying an identifier by its name, if several symbols with the same name exist, the debugger will prompt for the symbol you want to use. Pick up the one you want from its number.

In lots of cases, you can also use regular expressions for looking for a symbol.

winedbg defines its own set of variables. The configuration variables from above are part of them. Some others include:

The $ThreadId and $ProcessId variables can be handy to set conditional breakpoints on a given thread or process.

1.7.1. Misc

1.7.2. Flow control

cont, step, next, stepi, nexti can be postfixed by a number (N), meaning that the command must be executed N times.

1.7.3. Breakpoints, watch points

You can use the symbol EntryPoint to stand for the entry point of the Dll.

When setting a break/watch-point by <id>, if the symbol cannot be found (for example, the symbol is contained in a not yet loaded module), winedbg will recall the name of the symbol and will try to set the breakpoint each time a new module is loaded (until it succeeds).

1.7.4. Stack manipulation

1.7.5. Directory & source file manipulation

You can specify the end target (to change the 10 lines value) using the ','. For example:

1.7.6. Displaying

A display is an expression that's evaluated and printed after the execution of any winedbg command.

winedbg will automatically detect if the expression you entered contains a local variable. If so, display will only be shown if the context is still in the same function as the one the debugger was in when the display expression was entered.

1.7.7. Disassembly

1.7.8. Memory (reading, writing, typing)

/fmt is either /<letter> or /<count><letter> letter can be

1.7.9. Information on Wine's internals

1.7.10. Debug channels

It is possible to turn on and off debug messages as you are debugging using the set command. See Chapter 2 for more details on debug channels.

1.8.1. GDB mode

WineDbg can act as a remote monitor for GDB. This allows to use all the power of GDB, but while debugging wine and/or any Win32 application. To enable this mode, just add --gdb to winedbg command line. You'll end up on a GDB prompt. You'll have to use the GDB commands (not WineDbg's).

However, some limitation in GDB while debugging wine (see below) don't appear in this mode:

• GDB will correctly present Win32 thread information and breakpoint behavior

• Moreover, it also provides support for the Dwarf II debug format (which became the default format (instead of stabs) in gcc 3.1).

A few Wine extensions available through the monitor command.

1.8.2. Graphical frontends to gdb

This section will describe how you can debug Wine using the GDB mode of winedbg and some graphical front ends to GDB for those of you who really like graphical debuggers.

1.8.3. Using other Unix debuggers

You can also use other debuggers (like gdb), but you must be aware of a few items:

You need to attach the unix debugger to the correct unix process (representing the correct windows thread) (you can "guess" it from a ps fax for example: When running the emulator, usually the first two upids are for the Windows' application running the desktop, the first thread of the application is generally the third upid; when running a Winelib program, the first thread of the application is generally the first upid)

Here's how to get info about the current execution status of a certain Wine process:

Change into your Wine source dir and enter:

$ gdb wine
        

Switch to another console and enter ps ax | grep wine to find all wine processes. Inside gdb, repeat for all Wine processes:

(gdb) attach PID
        

with PID being the process ID of one of the Wine processes. Use

(gdb) bt
        

to get the backtrace of the current Wine process, i.e. the function call history. That way you can find out what the current process is doing right now. And then you can use several times:

(gdb) n
        

or maybe even

(gdb) b SomeFunction
        

and

(gdb) c
        

to set a breakpoint at a certain function and continue up to that function. Finally you can enter

(gdb) detach
        

to detach from the Wine process.

1.8.4. Using other Windows debuggers

You can use any Windows' debugging API compliant debugger with Wine. Some reports have been made of success with VisualStudio debugger (in remote mode, only the hub runs in Wine). GoVest fully runs in Wine.

1.8.5. Main differences between winedbg and regular Unix debuggers

4.2.1. Inline attachments with Outlook Express

Outlook Express is notorious for mangling attachments. Giving the patch a .txt extension and attaching will solve the problem for most mailers including Outlook. Also, there is a way to enable Outlook Express to send .diff attachments.

You need the following two things to make it work.

1. Make sure that .diff files have \r\n line ends, because if OE detects that there is no \r\n line endings it switches to quoted-printable format attachments.

2. Using regedit add key "Content Type" with value "text/plain" to the .diff extension under HKEY_CLASSES_ROOT (same as for .txt extension). This tells OE to use Content-Type: text/plain instead of application/octet-stream.

Item #1 is important. After you hit the "Send" button, go to "Outbox" and using "Properties" verify the message source to make sure that the mail has the correct format. You might want to send several test emails to yourself too.

4.2.2. Alexandre's Bottom Line

"The basic rules are: no attachments, no MIME crap, no line wrapping, a single patch per mail. Basically if I can't do "cat raw_mail | patch -p0" it's in the wrong format."