context probably won't give you any insight into what it actually
means, namely that because of X limitations, Wine can't actually
change the screen depth and lies to the application instead. Usually
this is fine; in fact I've never heard of it causing a problem. We
really have no business printing that scary useless thing IMO.
It should never be necessary to document these things. If, as in this
case, there is a common message that is basically never useful, it
should be probably be changed to a WARN or TRACE. If there is a
message that does commonly mean the same thing for users, that
information should be in the message itself, not buried in
documentation. For messages that rarely occur or are only meaningful
to programmers, the source code is enough.
> When it crashes, how does one interpret the crash details? Generic
information please - not specific.
> Mostly the documents do not exist and when I do find something it usually
assumes a lot of existing knowledge.
What you're asking for is impossible. You really need a lot of
existing knowledge. No royal road and such. I'm going to try anyway
because I am crazy.
Usually the only useful information you can get from crash details is:
1. What was the most immediate bad thing that happened?
2. What function tried to do the bad thing?
3. What functions called the function that tried to do the bad thing?
Usually, the error is an "unhandled page fault" on attempting to read,
write, or execute something. "Page fault" means the program is trying
to do something that does not make sense given its current memory
layout. For example, the address 0x00000000 usually is not assigned
any meaning. If a program tries to call a function at that address, it
will cause a page fault executing 0x00000000. The program has a chance
to recover from things like this; if it doesn't, it crashes.
A "read" is usually a pointer access (*somevar) or
(somevar->attribute), write is usually assignment (somevar = value) or
(somevar++), and execute is usually a function call
(somevar(arguments)).
The "Backtrace" is a list of functions that are currently being
executed. The first one is the one that is running at the time of the
crash. The second function called the first one, the third called the
second, etc. If any involved functions are in a Wine dll, and you have
debugging symbols, it should give you an exact line in the source code
and the values of variables that the time of the crash. If you can't
get this information (either you don't have debugging symbols or all
the involved functions are in a native windows exe or dll), the
backtrace is probably useless.
If you see the RaiseException function at the top of the trace, that
function isn't broken. It means either there's an unimplemented
function (in which case the log will also say "Call to unimplemented
function library.NameOfFunction"), or a program/library has
deliberately raised an exception (which, if not handled, causes a
crash).
If you have to gather more information about a crash, a good step is
often to get a +seh,+relay log and find the trace:seh:raise_exception
lines immediately before the crash. Often what happens just before
that is related.
Often crashes happen because something very bad happened earlier and
now something is wrong with the program state (e.g. somevar should
never be NULL, but now it is for some reason). The crash details only
give you a snapshot in time; they cannot tell you how the program got
into that state. If you can't infer the reason from looking at the
code, you need to gather more information.
> I have tried reading the source code with some limited success- but there
is quite a lot of it and it is hard to get an overview that way.
Windows API documentation helps a lot. MSDN (the Win32 and COM
Development section) is good for looking up specific functions or
areas. If you're really serious, you might even want to pick up a book
about programming for Windows in C.
Of course, you have to start with a good grasp of C.
> PS. There are good answers in the thread but there are also a lot of non
answers - and I am sorry this is a non answer as well.
And I just made it even worse. Whee...
