[Bug 35884] New: Visual Studio 20XX frequently calls CoGetCallerTID(), resulting in console spam due to stub
https://bugs.winehq.org/show_bug.cgi?id=35884 Bug ID: 35884 Summary: Visual Studio 20XX frequently calls CoGetCallerTID(), resulting in console spam due to stub Product: Wine Version: 1.7.15 Hardware: x86 OS: Linux Status: NEW Severity: enhancement Priority: P2 Component: ole32 Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Hello folks, as the summary says... not really harmful though. --- snip --- ... fixme:ole:CoGetCallerTID stub! fixme:ole:CoGetCallerTID stub! fixme:ole:CoGetCallerTID stub! fixme:ole:CoGetCallerTID stub! ... --- snip --- I'd prefer a real implementation over a 'FIXME once', it's not particularly hard to do. MSDN: http://msdn.microsoft.com/en-us/library/windows/desktop/ms680683%28v=vs.85%2... --- quote --- lpdwTID [out] Receives the apartment ID of the caller's thread. For a single threaded apartment (STA), this is the current thread ID. For a multithreaded apartment (MTA), the value is 0. For a neutral apartment (NA), the value is -1. --- quote --- Source: http://source.winehq.org/git/wine.git/blob/39562961283ccb7c838c5650b11873e69... --- snip --- 92 HRESULT WINAPI CoGetCallerTID(LPDWORD lpdwTID) 93 { 94 FIXME("stub!\n"); 95 return E_NOTIMPL; 96 } --- snip --- $ wine --version wine-1.7.15-112-g2aad5d7 Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=35884 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |leslie_alistair(a)hotmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=35884 --- Comment #1 from Austin English <austinenglish(a)gmail.com> --- This is your friendly reminder that there has been no bug activity for over a year. Is this still an issue in current (1.7.51 or newer) wine? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=35884 --- Comment #2 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, obviously still present. https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ole32/ole2stubs.c#l90 $ wine --version wine-1.7.51 Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=35884 --- Comment #3 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, revisiting, obviously still present. $ wine --version wine-4.3 Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=35884 --- Comment #4 from Nikolay Sivov <bunglehead(a)gmail.com> --- This does not look trivial in case of remote calls, I don't see how client tid could be communicated to the server. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=35884 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |https://download.microsoft. | |com/download/A/9/1/A91D6B2B | |-A798-47DF-9C7E-A97854B7DD1 | |8/VC.iso --- Comment #5 from Anastasius Focht <focht(a)gmx.net> --- Hello Nikolay, --- quote --- This does not look trivial in case of remote calls, I don't see how client tid could be communicated to the server. --- quote --- I don't know either, but I found this interesting piece of information about the location of COM caller/callee process and thread ids: https://stackoverflow.com/questions/41204672/problems-using-dbgrpc-on-window... ("Problems using dbgrpc on Windows7"): --- quote --- To avoid this kernel mess, I use the "ReservedForOle" pointer in the thread's TEB (offset 0xf80) where COM stores process and thread IDs. The following commands can be used to access them for WinDbg: In COM-server: where is an incoming COM-call is coming from: Caller's process ID: ? dwo(dwo(@$teb + 0xf80) + 0x108) Caller's thread ID (will be 0 if the caller's thread is in MTA, or -1 if in NA): ? dwo(dwo(@$teb + 0xf80) + 0x34) In COM-client: where is an outgoing COM-call going to: Target's process ID: ? dwo(dwo(@$teb + 0xf80) + 0x100) Target's thread ID (will be 0 if the target server is a MTA COM-server): ? dwo(dwo(@$teb + 0xf80) + 0x104) These values are for 32-bit processes. For native 64-bit processes, the offsets would be different (e.g. "ReservedForOle" is on the offset 0x1758 in TEB). --- quote --- At least we have explanation for the 'unknown' DWORD at offset +0x34 and more offsets. https://source.winehq.org/git/wine.git/blob/3b1c3e57fcac4e23c0f9b376a483c494... --- snip --- 163 /* this is what is stored in TEB->ReservedForOle */ 164 struct oletls 165 { 166 struct apartment *apt; 167 IErrorInfo *errorinfo; /* see errorinfo.c */ 168 DWORD thread_seqid;/* returned with CoGetCurrentProcess */ 169 DWORD apt_mask; /* apartment mask (+0Ch on x86) */ 170 void *unknown0; 171 DWORD inits; /* number of times CoInitializeEx called */ 172 DWORD ole_inits; /* number of times OleInitialize called */ 173 GUID causality_id; /* unique identifier for each COM call */ 174 LONG pending_call_count_client; /* number of client calls pending */ 175 LONG pending_call_count_server; /* number of server calls pending */ 176 DWORD unknown; 177 IObjContext *context_token; /* (+38h on x86) */ 178 IUnknown *call_state; /* current call context (+3Ch on x86) */ 179 DWORD unknown2[46]; 180 IUnknown *cancel_object; /* cancel object set by CoSetCancelObject (+F8h on x86) */ 181 IUnknown *state; /* see CoSetState */ 182 struct list spies; /* Spies installed with CoRegisterInitializeSpy */ 183 DWORD spies_lock; 184 }; --- snip --- Also adding download links. https://download.microsoft.com/download/A/9/1/A91D6B2B-A798-47DF-9C7E-A97854... (MS Visual C++ 2005 Express) Internet Archive Snapshot/Mirror: https://web.archive.org/web/20190127082540/http://download.microsoft.com/dow... $ sha1sum VC.iso 1ae44e4eaf8c61c3a39e573fd6efd9889e940529 VC.iso $ du -sh VC.iso 463M VC.iso $ wine --version wine-5.0-rc3 Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=35884 --- Comment #6 from Nikolay Sivov <bunglehead(a)gmail.com> --- Improved layout with more fields matching on x64 would be something like this: --- struct oletls { struct apartment *apt; IErrorInfo *errorinfo; /* see errorinfo.c */ DWORD thread_seqid;/* (+8h/+10h) returned with CoGetCurrentProcess */ DWORD apt_mask; /* (+Ch/+14h) apartment mask */ DWORD inits; DWORD_PTR unknown1; DWORD ole_inits; DWORD unknown2; DWORD_PTR unknown3[5]; DWORD caller_tid; /* (+34h/+58h) CoGetCallerTID() */ DWORD_PTR unknown4; IObjContext *context_token; /* (+38h/+68h on x86) */ IUnknown *call_state; /* current call context (+3Ch on x86) */ DWORD unknown5[12]; GUID causality_id; /* (+80h/+d8h) */ DWORD unknown6[18]; IUnknown *cancel_object; /* cancel object set by CoSetCancelObject (+F8h on x86) */ IUnknown *state; /* see CoSetState */ struct list spies; /* Spies installed with CoRegisterInitializeSpy */ DWORD spies_lock; LONG pending_call_count_client; /* number of client calls pending */ LONG pending_call_count_server; /* number of server calls pending */ }; --- So caller tid is at 0x58. Function seems to simply return this field value. Regarding actually implementing this, I think it could about the same as causality id being set/restored around RPC_ExecuteCall(), which real question being how this TID is communicated through RPC_MESSAGE. (This is probably limited to same machine case, or even for certain local protocols) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=35884 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- URL|https://download.microsoft. |https://web.archive.org/web |com/download/A/9/1/A91D6B2B |/20190127082540/http://down |-A798-47DF-9C7E-A97854B7DD1 |load.microsoft.com/download |8/VC.iso |/A/9/1/A91D6B2B-A798-47DF-9 | |C7E-A97854B7DD18/VC.iso --- Comment #7 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, revisiting, still present. $ wine --version wine-6.0 Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=35884 Steven Don <bugzilla-wine@shdon.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla-wine@shdon.com --- Comment #8 from Steven Don <bugzilla-wine@shdon.com> --- The linked documentation also mentions: --- quote --- Remarks If the caller is not running on the same computer, this function does not return the apartment ID and the return value is S_FALSE. --- quote --- Does that not cover the remote call scenario? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (3)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla
-
WineHQ Bugzilla