incomplete relay when accessed from winedbg

[Bill Medland]

Guys

Any chance of help on this?

I am trying to figure out why some numbers are misformatted through Crystal 
Reports ToText function.  (e.g. 6..0 instead of 599.95)

I tried to turn +relay on from within winedbg so that I could see just what 
functions got called.

All that relay gave me was "window proc", "hook proc" and wineps calls; no 
ntdll or anything else.

Any idea why it isn't giving me everything?

(wine 20040914)

[Eric Pouech]

Bill Medland a écrit :
> Guys
>
> Any chance of help on this?
>
> I am trying to figure out why some numbers are misformatted through Crystal 
> Reports ToText function.  (e.g. 6..0 instead of 599.95)
>
> I tried to turn +relay on from within winedbg so that I could see just what 
> functions got called.
>
> All that relay gave me was "window proc", "hook proc" and wineps calls; no 
> ntdll or anything else.
>
> Any idea why it isn't giving me everything?

basically relay (and snoop behaves the same time) is a two step process:
- when a native (resp. builtin) DLL is loaded and if snoop (resp. relay) is 
turned on, Wine, when resolving the imports to this DLL (and later when 
implementing GetProcAddress), instead of returning the real function 
implementation, in fact:
    1/ creates a thunk to call the real function
    2/ returns the address of this thunk
When the thunk is actually called, the thunk does:
    + printf some info on the call if snoop (resp. relay) is turned on
    + actually calls the real implementation
    + printf some info on the value returned from the call if snoop (resp. relay) 
is turned on
- which means that when you use winedbg (or taskmgr) to turn on the snoop (resp 
relay) debug channel, you only activate/deactivate the debug information on the 
DLLs loaded when the snoop (resp. relay) was on, not all DLLs which have been 
loaded since you started your app.
- to be complete, a few places in wine use the relay for other purpose than the 
ones I've just described (for example thunk in window proc calling) which is 
what you saw as traces

IMO, the best way to fix this would be (e.g. for relay, the same applied to snoop):
- create a second debug channel, distinct from relay, say relay_trigger
- on ntdll load, initialize the value of relay_trigger to the value of relay (as 
defined in registry & command line) (*)
- make the code (in dlls/ntdll/relay.c) called upon DLL loading depend on 
relay_trigger and keep the real tracing depend on the relay debug channel

(*) this could be refined to that relay is in fact set to 0 so that no traces 
are generated at startup, which won't in this setup

A+

[Mike Hearn]

Maybe you have RelayExclude/Include set in the config file? I had a
similar problem just now caused by that.

thanks -mike