> How does "file a bug" answer the question the OP asked? It doesn't. I posted information that did not answer the question. Someone else had already given what I thought was a good answer, and I thought bugzilla was worth mentioning. > Where are details of what the messages mean? (the answer usually seems to be "not much") They are in the source code. If, for example, you have this message: fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 32 to 16 X11DRV_XRandR_SetCurrentMode is the name of the function that printed this information. You can find the source code for that function by doing an identifier search for X11DRV_XRandR_SetCurrentMode at http://source.winehq.org/. >From there you can see the line of code in context. Of course, the 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...
