Debugging and userfriendliness

[whatbug]

I've been playing this MMORPG (Mabinogi if anyone cares) for a while and it worked alright in Wine for the longest time (it still had some issues mostly because it was stupidly using Internet Explorer for so much of it..) until Hackshield updated and decided to throw the 0x00000108 error when initializing.
So I figured I'd give the debugger a shot and try to figure out the issue to get back to playing.

The normal debugger is a pain. I don't even care that it's a terminal application, but there doesn't seem to be any possibility of automatically passing or skipping certain exceptions, or even general ones. So trying to get the debugger past the game's launcher is impossible. It throws so many attempted read at memory 0x00000000 exceptions you can't make any progress.

So instead I tried logging. The page suggested to use +relay with a few other bells to get a good starting point of what was going on. Due to the sheer immensity of code that's executed before the error is thrown, actually logging the surrounding code is an absolute nightmare. The log was at 2 GB before even loading HSUpdate.exe then my computer crashed from memory shortage.

I saw a mention of a toggle button for logging, sounded like what I needed. But there were two problems: 1) It's not updated for the current Wine. 2) It does not work when pressing the button on windows of spawned processes, which is required here (and in this case, is actually spawned from the process spawned by the original). Because of the second I didn't really want to bother fixing the first. I don't know anything about Wine's code structure so I have no idea where to start fixing 2 (though I gave it a shot, it didn't amount to anything).

Finally, I logged "trace+all,-relay,-snoop,-heap" which was able to succeed, but doesn't give me the specific information I need...

Needless to say +relay would be really nice to use. So I want to suggest to the devs to put some effort into making a more user-friendly debugger. As much as I like Wine, I don't want to go through the effort of figuring out how to patch it according to all your regulations. I just want my game to work, I don't care what I have to modify to do it, be it Wine or Hackshield. But being able to more manageably figure out what's causing it would be a great help in making the strides to fix it.

To help I want to offer my suggestions to cover my debugging needs. Feel free to add suggestions yourself.

First of all for winedbg:
A shutup feature - Make it stop reporting, stopping, etc. all the crap it would normally do it on until told otherwise. So basically, run the application as it would without having run winedbg until otherwise noted.

exception handling list - Constant exception interrupts are the bane of my cracking existence. I recommend having a list similar to the win32 debugger in IDA Pro 5.5 (see screenshot: http://i44.tinypic.com/zjwkub.jpg) where you select the exception by code to either stop execution, pass it to the program, or ignore it.
I would use IDA's debugger for my purposes but it doesn't continue onto child processes.

For WINEDEBUG environment variable:
until - To replace the idea of a keypress toggle entirely, I suggest the until keyword alternative (or similar). My idea for it is something as follows: -relay,until+process/autoup\\.exe/
The [mostly failed] attempt in syntax here is to be fairly backwards compatible. I noticed that at least in the latest version, the class is ignored if it's not valid, still allowing -relay and +process to be set. Of course backwards compatibility would fail at that regex match after process..
What it's supposed to mean though, is that logging will be -relay until a log generated by +process matches the given regex, at which point the prior command would be inverted (-relay would become +relay).
This suggestion of implementation is probably no where near easy or feasible, it's only meant as a stepping stone to the idea of needing some form of programmable delay to logging.

HELP: Wine really REALLY needs some form of help command that can explain the debug channels. A lot are self explanatory, but then a lot aren't. Having the author or someone knowledgeable of the channel write a little blip on what kind of things it logs, or what it's used for would be invaluable to newcomers. As, as far as I can tell, there's no descriptive list of the channels anywhere.

+address: Log the address of the command being executed to form this log so people can reference it in a dissassembly of the program.

+jumps: Log jumps taken. This would help in finding what cmp/test is causing the jCC to the error so I can nop/jmp it as necessary. It's not a legitimate error in my case anyway, probably just some other "anti-hacking" technique that really only keeps you from running legitimate programs alongside the damn thing.


And lastly, some kind of debug config tool would be super nice. In similar style to the winecfg. It would just bring together all the obscure registry edits and flags and crap that goes into debugging, with a nice little run box and file selector for both the executable and the log file.

Thanks for hearing me out, and I hope to god debugging gets more friendly over time. :]

[whatbug]

bump

[dimesio]

bump

1. Don't do that. Users on the mailing list will have no idea what this is about.
2. There was no question in your original post. What do you want?

[jeffz]

HELP: Wine really REALLY needs some form of help command that can explain the debug channels.

You can do this by introspection:

They're listed in the source, usually near the top of the source file that uses the debug channel. The debug channels are usually familiar to anyone who is working with the code

[Gert van den Berg]

On Sun, May 16, 2010 at 13:50, jeffz <[email protected]> wrote:

whatbug wrote:

HELP: Wine really REALLY needs some form of help command that can explain the debug channels.

You can do this by introspection:

They're listed in the source, usually near the top of the source file that uses the debug channel.  The debug channels are usually familiar to anyone who is working with the code

They are also here:
http://wiki.winehq.org/DebugChannels

[James Mckenzie]

Gert:

There is more on that page than just the list.

There are hints on how to use them and when and why they should be used.

I think the page needs a rename to "The how, when, where, when and what of Wine's Debug channels"

What does the rest of the community think?

James McKenzie



-----Original Message-----

From: Gert van den Berg <[email protected]>
Sent: May 16, 2010 8:20 AM
To: [email protected]
Subject: Re: [Wine] Debugging and userfriendliness

On Sun, May 16, 2010 at 13:50, jeffz <[email protected]> wrote:

whatbug wrote:

HELP: Wine really REALLY needs some form of help command that can explain the debug channels.

You can do this by introspection:

They're listed in the source, usually near the top of the source file that uses the debug channel.  The debug channels are usually familiar to anyone who is working with the code

They are also here:
http://wiki.winehq.org/DebugChannels

[dimesio]

I think the page needs a rename to "The how, when, where, when and what of Wine's Debug channels"

What does the rest of the community think?

That it's a ridiculously long name for a wiki page, searching the wiki for "debug channels" will already bring up that page, and the page itself does not include anywhere near the level of detail your title implies or the OP was asking for.

[whatbug]

dimesio: It was intended as discussion rather than as a question.
jeffz: Thanks for the tip on the debug channels.
Gert: That only really explains like four of the debug channels, doesn't help with the rest of the list. So, yes, what dimesio said in his/her last post.

On the topic of better debugging though, I did find this. Haven't set it up yet though cause wine can't run the main exe for it and I haven't had the time to kick it around much yet.
Looks much better than the normal wine debugger from its description, particularly in the actually being able to ignore access violations.
So I'll try this route for now cause I don't think implementing a new debugging system in wine would take any short of a year.

[Gert van den Berg]

I had a draft typed out (since discarded...) with some other
suggestions.... (Typing what I remember below)

Suggestion on how to use the Debug channels would be useful (even for
non-Wine uses), as well as a short description of which each one
does...

Something like a section:" Using Wine debugging for
reverse-engineering (network) protocols", "Debug options useful for
installers", "Debugging graphics issues", etc... (About protocol
reverse engineering: Wine potentially allows the use user to see
within SSL tunnels, etc, which makes it more useful than Wireshark...)

Gert