Troubleshooting / Reporting bugsWhat to do if some program still doesn't work ?
There are times when you've been trying everything, you even killed a cat
at full moon and ate it with rotten garlic and foul fish
while doing the Devil's Dance, yet nothing helped to make some damn
program work on some Wine version.
Don't despair, we're here to help you...
(in other words: how much do you want to pay ?)
Run "winecheck" to check your configuration
Run a Perl script called winecheck, to be
found in Wine's tools/ directory.
The latest version can always be found at
http://home.arcor.de/andi.mohr/download/winecheck.
Make sure to run chmod +x winecheck first before
trying to execute it...
(or alternatively run it via perl ./winecheck)
The winecheck output will be a percentage score indicating Wine
configuration correctness.
Note that winecheck is only alpha, so it's not very complete or
100% accurate.
Use different windows version settings
In several cases using different windows version settings can help.
Use different startup paths
This sometimes helps, too:
Try to use both
wine prg.exe
and
wine x:\\full\\path\\to\\prg.exeFiddle with DLL configuration
Run with --debugmsg +loaddll to figure out which DLLs are
being used, and whether they're being loaded as native or
builtin.
Then make sure you have proper native DLL files in your
configured C:\windows\system directory and fiddle with DLL
load order settings at command line or in config file.
Check your system environment !
Just an idea: could it be that your Wine build/execution
environment is broken ?
Make sure that there are no problems whatsoever with the
packages
that Wine depends on (gcc, glibc, X libraries, OpenGL (!), ...)
E.g. some people have strange failures to find stuff when
using "wrong" header files for the "right" libraries !!!
(which results in days of debugging to desperately try to find
out why that lowlevel function fails in a way that is completely
beyond imagination... ARGH !)
Use different GUI (Window Manager) modes
Instruct Wine via config file to use either desktop mode,
managed mode or plain ugly "normal" mode.
That can make one hell of a difference, too.
Check your app !
Maybe your app is using some kind of copy protection ?
Many copy protections currently don't work on Wine.
Some might work in the future, though.
(the CD-ROM layer isn't really full-featured yet).
Go to GameCopyWorld
and try to find a decent crack for your game that gets rid of
that ugly copy protection.
I hope you do have a legal copy of the program, though... :-)
Check your Wine environment !
Running with or without a Windows partition can have a
dramatic impact.
Configure Wine to do the opposite of what you used to have.
Also, install DCOM98 or DCOM95. This can be very beneficial.
Reconfigure Wine
Sometimes wine installation process changes and new versions of
Wine acccount on these changes.
This is especially true if your setup was created long time ago.
Rename your existing ~/.wine directory
for backup purposes.
Use the setup process that's recommended for your Wine distribution
to create new configuration.
Use information in old ~/.wine
directory as a reference.
For source wine distribution to configure Wine run
tools/wineinstall script as a user you want to do the configuration
for.
This is a pretty safe operation. Later you can remove the new
~/.wine directory and rename your old one back.
Check out further information
Check out the Wine Troubleshooting Guide on WineHQ.
Go to Google Groups
and check whether some guys are smarter than you ;-)
(well, whether they found a solution to the problem, that is)
Go to WineHQ's
Application Database and check whether
someone posted the vital config hint for your app.
If that doesn't help, then consider going to
irc.openprojects.net channel #WineHQ, posting to
news:comp.emulators.ms-windows.wine or mailing to the wine-users
(or maybe sometimes even wine-devel) mailing lists.
Debug it!
Have you used the Search feature of the Wine Troubleshooting Guide ?? (i.e. are you sure there's no answer ?)
If you have, then try
The Perfect Enduser Wine Debugging Guide, and of
course don't forget to read the Wine Developers Guide.
How To Report A Bug
Written by (???)
(Originally extracted from wine/documentation/bugreports)
There are two ways for you to make a bug report. One uses a
simple perl script, and is recommended if you don't want to
spend a lot of time producing the report. It is designed for
use by just about anyone, from the newest of newbies to
advanced developers. You can also make a bug report the hard
way -- advanced developers will probably prefer this.
When using either approach please report the problem you found
along with any relevant information to
Wine Bugzilla.
The Easy Way
Your computer must have perl on it
for this method to work. To find out if you have perl,
run which perl. If it returns something like
/usr/bin/perl, you're in business.
Otherwise, skip on down to "The Hard Way". If you aren't
sure, just keep on going. When you try to run the
script, it will become very apparent
if you don't have perl.
Change directory to <dirs to
wine>/tools
Type in ./bug_report.pl and follow
the directions.
Post the bug to
Wine Bugzilla.
Please, search Bugzilla database to check whether your problem is
already found before posting a bug report.
Include your own detailed description of the problem with
relevant information. Attach the "Nice Formatted Report"
to the submitted bug. Do not cut and paste the report
in the bug description - it is pretty big.
Keep the full debug output in case it will be needed by
Wine developers.
The Hard Way
Some simple advice on making your bug report more useful
(and thus more likely to get answered and fixed):
Post as much information as possible.
This means we need more information than a simple "MS
Word crashes whenever I run it. Do you know why?"
Include at least the following information:
Version of Wine you're using (run wine
-v)
Operating system you're using, what distribution (if
any), and what version
Compiler and version (run gcc -v)Windows version, if used with Wine.
Mention if you don't use Windows
Program you're trying to run, its version number,
and a URL for where the program can be obtained (if
available)
Command line you used to start wine
Any other information you think may be relevant or
helpful, such as X server version in case of X
problems, libc version etc.
Re-run the program with the --debugmsg
+relay option (i.e., wine
--debugmsg +relay sol.exe).
If Wine crashes while running your program, it is
important that we have this information to have a chance
at figuring out what is causing the crash. This can put
out quite a lot (several MB) of information, though, so
it's best to output it to a file. When the Wine-dbg>
prompt appears, type quit.
You might want to try
+relay,+snoop instead of
+relay, but please note that
+snoop is pretty unstable and
often will crash earlier than a simple
+relay! If this is the case, then
please use only+relay!! A bug
report with a crash in +snoop
code is useless in most cases!
You can also turn on other parameters, depending on the nature
of the problem you are researching. See wine man page for full list
of the parameters.
To get the trace output, use the following commands:
all shells:$ echo quit | wine -debugmsg +relay [other_options] program_name >& filename.out;
$ tail -n 100 filename.out > report_file
(This will print wine's debug messages only to the file and then
auto-quit. It's probably a good idea to use this command, since wine
prints out so many debug msgs that they flood the terminal, eating CPU.)
tcsh and other csh-like shells:$ wine -debugmsg +relay [other_options] program_name |& tee filename.out;
$ tail -100 filename.out > report_file
bash and other sh-like shells:$ wine -debugmsg +relay [other_options] program_name 2>&1 | tee filename.out;
$ tail -100 filename.out > report_file
report_file will now contain the
last hundred lines of the debugging output, including
the register dump and backtrace, which are the most
important pieces of information. Please do not delete
this part, even if you don't understand what it means.
Post the bug to Wine Bugzilla.
Please, search the Bugzilla database to check whether your problem
is already reported. If it is already reported attach the bug report
and add any other relevant information to the original bug report.
In your post, include all of the information from part
1), and attach to the bug the output file in part 2).
If you do this, your chances of receiving some sort of
helpful response should be very good.