[Bug 50849] New: Streamdeck MSI installation fails

List overview All Threads

newer

older

[Bug 10924] New: Netbeans 6...

[Bug 52062] New: dinput HID...

WineHQ Bugzilla

23 Mar 2021 23 Mar '21

8:41 a.m.

https://bugs.winehq.org/show_bug.cgi?id=50849

Bug ID: 50849 Summary: Streamdeck MSI installation fails Product: Wine Version: 6.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: viraptor@gmail.com Distribution: ---

Created attachment 69664 --> https://bugs.winehq.org/attachment.cgi?id=69664 log of running the installer

The installer for Streamdeck app (available from https://www.elgato.com/en/downloads ; tested version https://edge.elgato.com/egc/windows/sd/Stream_Deck_4.9.3.13222.msi ) fails with the installer saying "Elgato Stream Deck Setup Wizard ended prematurely because of an error".

Full log attached, but the main error seems to be in this fragment:

0108:fixme:mscoree:corruntimehost_UnloadDomain stub 000000000008C160 0108:fixme:mscoree:corruntimehost_Stop stub 000000000008C160 0024:err:msi:custom_get_thread_return Invalid Return Code 68870160 0024:err:msi:ITERATE_Actions Execution halted, action L"DeleteInvalidPathRegistryKey" returned 1603

-- 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.

Show replies by date

WineHQ Bugzilla

23 Mar 23 Mar

6:48 p.m.

New subject: [Bug 50849] Elgato Stream Deck 4.9.3 (.NET 4.5 app) installer: invocation of managed custom action 'DeleteInvalidPathRegistryKey' returns incorrect result with Wine-Mono

https://bugs.winehq.org/show_bug.cgi?id=50849

Anastasius Focht focht@gmx.net changed:

--- Comment #1 from Anastasius Focht focht@gmx.net --- Hello folks,

confirming. It's a .NET 4.5 app which requires 'Windows 10' setting.

Using native .NET Framework 4.5 ('winetricks --force -q dotnet45') works around - only to run into the next bug.

--- snip --- $ WINE_MONO_VERBOSE=1 WINEDEBUG=+seh,+loaddll,+mscoree,+relay,+msi wine msiexec -i Stream_Deck_4.9.3.13222.msi ... 0024:trace:msi:ACTION_CustomAction Handling custom action L"DeleteInvalidPathRegistryKey" (1 L"StreamDeckCustomAction.CA.dll" L"DeleteRegistryEntryIfNeeded") ... 0108:Call KERNEL32.CreateProcessW(0150e690 L"C:\windows\system32\rundll32.exe",0150eab0 L"rundll32.exe "C:\users\focht\Temp\msi30b8.tmp",zzzzInvokeManagedCustomActionOutOfProc SfxCA_13906298 1 StreamDeckCustomAction!StreamDeckCustomAction.CustomActions.DeleteRegistryEntryIfNeeded",00000000,00000000,00000000,00000000,00000000,00000000,0150e550,0150e4b8) ret=01523037 ... 011c:trace:mscoree:DllMain (0000000001390000, 1, 0000000000000000) 011c:trace:mscoree:GetRequestedRuntimeInfo (L"C:\users\focht\Temp\msi96a0.tmp-\Microsoft.Deployment.WindowsInstaller.dll", (null), L"C:\users\focht\Temp\msi96a0.tmp-\CustomAction.config", 0x00000000, 0x00000000, 000000000022F040, 0x00000104, 0000000000000000, 000000000022F018, 0x00000014, 0000000000000000) 011c:trace:mscoree:CreateConfigStream (L"C:\users\focht\Temp\msi96a0.tmp-\CustomAction.config", 000000000022EA00) ... Method int Microsoft.Deployment.WindowsInstaller.CustomActionProxy:InvokeCustomAction64 (int,string,long) emitted at 000000000c880520 to 000000000c880579 (code length 89) [CustomAction] Method (wrapper runtime-invoke) object <Module>:runtime_invoke_int_int_object_long (object,intptr,intptr,intptr) emitted at 000000000c8805a0 to 000000000c880780 (code length 480) [CustomAction] Method int Microsoft.Deployment.WindowsInstaller.CustomActionProxy:InvokeCustomAction (int,string,intptr) emitted at 000000000c880790 to 000000000c881021 (code length 2193) [CustomAction] Method System.Delegate System.Runtime.InteropServices.Marshal:GetDelegateForFunctionPointer (intptr,System.Type) emitted at 000000000c8810e0 to 000000000c8812c3 (code length 483) [CustomAction] Method (wrapper managed-to-native) System.Delegate System.Runtime.InteropServices.Marshal:GetDelegateForFunctionPointerInternal (intptr,System.Type) emitted at 000000000c8812e0 to 000000000c8813ed (code length 269) [CustomAction] Method (wrapper managed-to-native) void object:wrapper_native_0000000000ae3134 (Microsoft.Deployment.WindowsInstaller.RemoteMsiFunctionId,intptr,intptr&) emitted at 000000000c881400 to 000000000c88154d (code length 333) [CustomAction] Method void Microsoft.Deployment.WindowsInstaller.RemotableNativeMethods:set_RemotingDelegate (Microsoft.Deployment.WindowsInstaller.MsiRemoteInvoke) emitted at 000000000c881570 to 000000000c881672 (code length 258) [CustomAction] ... Method Microsoft.Deployment.WindowsInstaller.ActionResult StreamDeckCustomAction.CustomActions:DeleteRegistryEntryIfNeeded (Microsoft.Deployment.WindowsInstaller.Session) emitted at 000000000cb6ad10 to 000000000cb6aefd (code length 493) [CustomAction] ... Method Microsoft.Deployment.WindowsInstaller.ActionResult StreamDeckCustomAction.CustomActions:DeleteRegistryEntryIfNeeded (Microsoft.Deployment.WindowsInstaller.Session) emitted at 000000000cb6ad10 to 000000000cb6aefd (code length 493) [CustomAction] Method (wrapper runtime-invoke) object <Module>:runtime_invoke_ActionResult_object (object,intptr,intptr,intptr) emitted at 000000000cb6af30 to 000000000cb6b0f0 (code length 448) [CustomAction] Method (wrapper remoting-invoke-with-check) Microsoft.Win32.RegistryKey Microsoft.Win32.RegistryKey:OpenSubKey (string,bool) emitted at 000000000cb6b100 to 000000000cb6b1b9 (code length 185) [CustomAction] Method Microsoft.Win32.RegistryKey Microsoft.Win32.RegistryKey:OpenSubKey (string,bool) emitted at 000000000cb6b1f0 to 000000000cb6b291 (code length 161) [CustomAction] Method void Microsoft.Win32.RegistryKey:ValidateKeyName (string) emitted at 000000000cb6b2d0 to 000000000cb6b40d (code length 317) [CustomAction] ... Method int Microsoft.Win32.RegistryKey:GetRegistryKeyAccess (bool) emitted at 000000000cb6c5e0 to 000000000cb6c601 (code length 33) [CustomAction] Method (wrapper managed-to-native) int Interop/Advapi32:RegOpenKeyEx (Microsoft.Win32.SafeHandles.SafeRegistryHandle,string,int,int,Microsoft.Win32.SafeHandles.SafeRegistryHandle&) emitted at 000000000cb6c620 to 000000000cb6c910 (code length 752) [CustomAction] Method void Microsoft.Win32.SafeHandles.SafeRegistryHandle:.ctor () emitted at 000000000cb6c930 to 000000000cb6c979 (code length 73) [CustomAction] Method void System.NullReferenceException:.ctor () emitted at 000000000cb6c990 to 000000000cb6c9e4 (code length 84) [CustomAction] Method (wrapper runtime-invoke) object object:runtime_invoke_void__this__ (object,intptr,intptr,intptr) emitted at 000000000cb6ca00 to 000000000cb6cb68 (code length 360) [CustomAction] Method string System.Exception:get_Message () emitted at 000000000cb6cb80 to 000000000cb6cc70 (code length 240) [CustomAction] Method (wrapper remoting-invoke-with-check) void Microsoft.Deployment.WindowsInstaller.Session:Log (string) emitted at 000000000cb6cc90 to 000000000cb6cd45 (code length 181) [CustomAction] Method (wrapper managed-to-native) object object:__icall_wrapper_mono_thread_get_undeniable_exception () emitted at 000000000c872280 to 000000000c87237d (code length 253) [rundll32.exe] Method (wrapper remoting-invoke-with-check) void Microsoft.Deployment.WindowsInstaller.InstallerHandle:Close () emitted at 000000000cb6cd70 to 000000000cb6ce19 (code length 169) [CustomAction] Method void Microsoft.Deployment.WindowsInstaller.InstallerHandle:Close () emitted at 000000000cb6ce50 to 000000000cb6ce9d (code length 77) [CustomAction] Method (wrapper remoting-invoke-with-check) void Microsoft.Deployment.WindowsInstaller.InstallerHandle:Dispose () emitted at 000000000cb6cec0 to 000000000cb6cf69 (code length 169) [CustomAction] Method void Microsoft.Deployment.WindowsInstaller.Session:Dispose (bool) emitted at 000000000cb6cfa0 to 000000000cb6d07e (code length 222) [CustomAction] Method void System.Runtime.InteropServices.Marshal:GetNativeVariantForObject (object,intptr) emitted at 000000000c872390 to 000000000c872451 (code length 193) [rundll32.exe] ... 011c:fixme:mscoree:corruntimehost_UnloadDomain stub 000000000007BED0 011c:fixme:mscoree:corruntimehost_Stop stub 000000000007BED0 011c:trace:loaddll:free_modref Unloaded module L"C:\windows\system32\api-ms-win-core-localization-l1-2-1.dll" : builtin 011c:trace:loaddll:free_modref Unloaded module L"C:\windows\system32\api-ms-win-core-fibers-l1-1-1.dll" : builtin 011c:trace:loaddll:free_modref Unloaded module L"C:\windows\system32\api-ms-win-core-synch-l1-2-0.dll" : builtin 011c:trace:loaddll:free_modref Unloaded module L"C:\users\focht\Temp\msi96a0.tmp" : native ... Method (wrapper runtime-invoke) object <Module>:runtime_invoke_void_object_intptr_byte (object,intptr,intptr,intptr) emitted at 000000000c873160 to 000000000c8732f0 (code length 400) [rundll32.exe] ... 011c:trace:mscoree:CorExitProcess (0) 011c:trace:mscoree:CLRMetaHost_ExitProcess 0 converting method (wrapper managed-to-native) void System.Environment:Exit (int) Method (wrapper managed-to-native) void System.Environment:Exit (int) emitted at 000000000c873300 to 000000000c8733f5 (code length 245) [rundll32.exe] ... 011c:trace:mscoree:CorExitProcess (0) 011c:trace:mscoree:CLRMetaHost_ExitProcess 0 011c:trace:mscoree:_CorDllMain (000000000CB50000, 0, 0000000000000001) 011c:trace:mscoree:_CorDllMain (000000000CB20000, 0, 0000000000000001) 011c:trace:mscoree:_CorDllMain (000000000C880000, 0, 0000000000000001) 011c:trace:mscoree:_CorDllMain (0000000010000000, 0, 0000000000000001) 011c:trace:mscoree:_CorDllMain (00000000036D0000, 0, 0000000000000001) 011c:trace:mscoree:DllMain (0000000001390000, 0, 0000000000000001) 0108:trace:loaddll:free_modref Unloaded module L"C:\windows\system32\api-ms-win-core-localization-l1-2-1.dll" : builtin 0108:trace:loaddll:free_modref Unloaded module L"C:\windows\system32\api-ms-win-core-fibers-l1-1-1.dll" : builtin 0108:trace:loaddll:free_modref Unloaded module L"C:\windows\system32\api-ms-win-core-synch-l1-2-0.dll" : builtin 0108:trace:loaddll:free_modref Unloaded module L"C:\users\focht\Temp\msi96a0.tmp" : native 0024:err:msi:custom_get_thread_return Invalid Return Code 68793744 0024:err:msi:ITERATE_Actions Execution halted, action L"DeleteInvalidPathRegistryKey" returned 1603 ... --- snip ---

The exception in managed code (NullReferenceException) is also present with native .NET Framework = ok.

The installer runs a custom action on MSI CA server side which re-launches the custom action as a separate 'rundll32' process. That custom 'rundll32' CA server creates an app domain to run managed code. It communicates using pipes between the MSI custom action server which hosts the CA dll and the 'rundll32' CA server which hosts the managed bits.

Pretty much this code 'InvokeOutOfProcManagedCustomAction':

https://github.com/wixtoolset/wix3/blob/2ed6d7906c87bb65b75cfa0020e38a1b1dff...

The 'Invalid Return Code 68845504' is the interesting part. The return code is remoted across the app installer's own custom action server to the MSI custom action server before app domain shutdown.

https://github.com/wixtoolset/wix3/blob/2ed6d7906c87bb65b75cfa0020e38a1b1dff...

--- snip --- bool InvokeManagedCustomAction(MSIHANDLE hSession, _AppDomain* pAppDomain, const wchar_t* szEntryPoint, int* piResult) { VARIANT vResult; ::VariantInit(&vResult);

const bool f64bit = (sizeof(void*) == sizeof(LONGLONG)); const wchar_t* szMsiAssemblyName = L"Microsoft.Deployment.WindowsInstaller"; const wchar_t* szMsiCAProxyClass = L"Microsoft.Deployment.WindowsInstaller.CustomActionProxy"; const wchar_t* szMsiCAInvokeMethod = (f64bit ? L"InvokeCustomAction64" : L"InvokeCustomAction32");

_MethodInfo* pCAInvokeMethod; if (!GetMethod(hSession, pAppDomain, szMsiAssemblyName, szMsiCAProxyClass, szMsiCAInvokeMethod, &pCAInvokeMethod)) { return false; }

HRESULT hr; VARIANT vNull; vNull.vt = VT_EMPTY; SAFEARRAY* saArgs = SafeArrayCreateVector(VT_VARIANT, 0, 3); VARIANT vSessionHandle; vSessionHandle.vt = VT_I4; vSessionHandle.intVal = hSession; LONG index = 0; hr = SafeArrayPutElement(saArgs, &index, &vSessionHandle); if (FAILED(hr)) goto LExit; VARIANT vEntryPoint; vEntryPoint.vt = VT_BSTR; vEntryPoint.bstrVal = SysAllocString(szEntryPoint); if (vEntryPoint.bstrVal == NULL) { hr = E_OUTOFMEMORY; goto LExit; } index = 1; hr = SafeArrayPutElement(saArgs, &index, &vEntryPoint); if (FAILED(hr)) goto LExit; VARIANT vRemotingFunctionPtr; #pragma warning(push) #pragma warning(disable:4127) // conditional expression is constant if (f64bit) #pragma warning(pop) { vRemotingFunctionPtr.vt = VT_I8; vRemotingFunctionPtr.llVal = (LONGLONG) (g_fRunningOutOfProc ? MsiRemoteInvoke : NULL); } else { vRemotingFunctionPtr.vt = VT_I4; #pragma warning(push) #pragma warning(disable:4302) // truncation #pragma warning(disable:4311) // pointer truncation vRemotingFunctionPtr.lVal = (LONG) (g_fRunningOutOfProc ? MsiRemoteInvoke : NULL); #pragma warning(pop) } index = 2; hr = SafeArrayPutElement(saArgs, &index, &vRemotingFunctionPtr); if (FAILED(hr)) goto LExit;

hr = pCAInvokeMethod->Invoke_3(vNull, saArgs, &vResult);

LExit: SafeArrayDestroy(saArgs); pCAInvokeMethod->Release();

if (FAILED(hr)) { Log(hSession, L"Failed to invoke custom action method. Error code 0x%X", hr); return false; }

*piResult = vResult.intVal; return true; } --- snip ---

--- snip --- pCAInvokeMethod->Invoke_3(vNull, saArgs, &vResult); --- snip ---

'Microsoft.Deployment.WindowsInstaller.CustomActionProxy.InvokeCustomAction64'

That invoke is a proxy which then invokes the real managed custom action. The result code should be propagated from the inner "real" managed method invocation within 'CustomActionProxy.InvokeCustomAction'

I managed to break into the managed CA and dump the 'vResult' VARIANT after the "proxy" 'InvokeCustomAction' (after returning from CLR/managed code).

--- snip --- 000000000022F270 09 00 00 00 00 00 00 00 20 DE 18 04 --- snip ---

vt: 0x9 = VT_DISPATCH value: 0x0418DE20 = 68738592

That's obviously wrong. Debugging dynamically generated code/reflection invocation is not very fun.

Unfortunately there is another bug with Wine-Mono that prevents a full trace with 'WINE_MONO_TRACE=all'. Using that causes an internal crash in Wine-Mono much earlier.

$ sha1sum Stream_Deck_4.9.3.13222.msi d54a6df51519c5028eeb27b8f1a577d50a62e375 Stream_Deck_4.9.3.13222.msi

$ du -sh Stream_Deck_4.9.3.13222.msi 96M Stream_Deck_4.9.3.13222.msi

$ wine --version wine-6.4

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.

WineHQ Bugzilla

11 Apr 11 Apr

8:49 a.m.

New subject: [Bug 50849] Multiple .NET 4.x app installers using WiX v3 'InvokeOutOfProcManagedCustomAction, CAInvokeMethod->Invoke_3 return incorrect result with Wine-Mono (Elgato Stream Deck 4.9.3, Garmin Express 6.13)

https://bugs.winehq.org/show_bug.cgi?id=50849

Anastasius Focht focht@gmx.net changed:

--- Comment #2 from Anastasius Focht focht@gmx.net --- Hello folks,

refining summary.

Garmin Express 6.13 installer from bug 46613 is also affected.

Download link via Internet Archive:

https://web.archive.org/web/20190424051657/https://download.garmin.com/omt/e...

$ wine --version wine-6.6

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.

WineHQ Bugzilla

30 Apr 30 Apr

4:39 p.m.

https://bugs.winehq.org/show_bug.cgi?id=50849

--- Comment #3 from Esme Povirk madewokherd@gmail.com --- Thanks for tracking this down. pCAInvokeMethod is declared as a _MethodInfo, which is an interface defined in the standard library. Based on signatures, I think Invoke_3 is this method:

Object Invoke(Object obj, Object[] parameters);

MSDN link: https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices._...

The Object return value is implicitly pulled into an output parameter and HRESULT return on the COM side.

Given they're accessing this through intVal, I guess they expect a VT_INT or VT_I4.

Variant marshaling goes through the Marshal.GetNativeVariantForObject method, so we can trace that to find the object being converted: [0000000000000130: 0.00000 0] ENTER:c System.Runtime.InteropServices.Marshal:GetNativeVariantForObject (object,intptr)([INT32:0000000001c596c8:0], 000000000061f2b0)

By examination of System.Variant.SetValue, that should produce a VT_I4, so something weird is going on here.

-- 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.

WineHQ Bugzilla

4:48 p.m.

https://bugs.winehq.org/show_bug.cgi?id=50849

--- Comment #4 from Esme Povirk madewokherd@gmail.com --- The issue seems to be that the comparison (t == typeof(int)) doesn't work as expected, we have a reference to the System.Int32 type on both sides, but they are not identical object references.

It should probably be using the Equals method.

-- 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.

WineHQ Bugzilla

5:01 p.m.

https://bugs.winehq.org/show_bug.cgi?id=50849

--- Comment #5 from Esme Povirk madewokherd@gmail.com --- Equals doesn't work either. I'm not sure what's different about the Type object we're getting, it clearly represents the System.Int32 type, but they don't compare as equal.

-- 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.

WineHQ Bugzilla

5:09 p.m.

https://bugs.winehq.org/show_bug.cgi?id=50849

--- Comment #6 from Esme Povirk madewokherd@gmail.com --- Using IsInstanceOfType works, but of course that's wrong because it won't handle enum types correctly.

-- 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.

WineHQ Bugzilla

6:05 p.m.

https://bugs.winehq.org/show_bug.cgi?id=50849

--- Comment #7 from Esme Povirk madewokherd@gmail.com --- It turns out that both -- and Equals use reference equality, and there's only supposed to be one Type object for a given type. The code in Variant.SetValue appears to be correct, but something strange is happening in the runtime.

-- 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.

WineHQ Bugzilla

6:57 p.m.

https://bugs.winehq.org/show_bug.cgi?id=50849

--- Comment #8 from Esme Povirk madewokherd@gmail.com --- OK, so I have a theory about what's happening. The application creates a second AppDomain named CustomAction. It then uses the _AppDomain COM interface and related things to run code in it. The cominterop wrappers for these interfaces will ensure that the methods are run in the correct domain.

Here's the problem: Object marshaling happens outside of the cominterop wrapper, in the native-to-managed wrapper, so it runs in the default domain. So GetNativeVariantForObject is running on the default domain, which has one set of Type objects, but it's working with objects created by the CustomAction domain, which have another set of Type objects.

We could fix the type comparisons so that they work with objects from another domain (which isn't supposed to ever happen), but that won't really solve the problem. Any object created by marshaling inputs will be from the default domain and may behave weirdly. Also, COM interfaces created on output may be wrong.

I don't know how to fix this, at least not without a redesign of the cominterop code to pull all object marshaling into the cominterop wrapper.

-- 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.

WineHQ Bugzilla

7:25 p.m.

https://bugs.winehq.org/show_bug.cgi?id=50849

--- Comment #9 from Esme Povirk madewokherd@gmail.com --- Or I guess add a flag to mono_marshal_emit_managed_wrapper, to have it call some cominterop functions to generate domain change code before and after the marshaling code.

-- 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.

WineHQ Bugzilla

12 May 12 May

2:59 a.m.

https://bugs.winehq.org/show_bug.cgi?id=50849

Zebediah Figura z.figura12@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com

--- Comment #10 from Zebediah Figura z.figura12@gmail.com --- I don't particularly expect one, but is there an explanation of how domains are supposed to work? Just from skimming, it seems like it's set for the thread; why is code on the thread running in a different domain?

-- 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.

WineHQ Bugzilla

9:40 p.m.

https://bugs.winehq.org/show_bug.cgi?id=50849

--- Comment #11 from Bruni earns.61@gmail.com --- (In reply to Zebediah Figura from comment #10)

...

I don't particularly expect one, but is there an explanation of how domains are supposed to work? Just from skimming, it seems like it's set for the thread; why is code on the thread running in a different domain?

--Quote from Microsoft--

[...] Cross-domain calls use the same remote call infrastructure as calls between two processes or between two machines. As such, the metadata for the object being referenced must be available to both application domains to allow the method call to be JIT-compiled properly. If the calling domain does not have access to the metadata for the object being called, the compilation might fail with an exception of type FileNotFoundException. For more information, see Remote Objects. The mechanism for determining how objects can be accessed across domains is determined by the object. For more information, see System.MarshalByRefObject.

[...]

An application domain forms an isolation boundary for security, versioning, reliability, and unloading of managed code. A thread is the operating system construct used by the common language runtime to execute code. At run time, all managed code is loaded into an application domain and is run by one or more managed threads.

There is not a one-to-one correlation between application domains and threads. Several threads can execute in a single application domain at any given time, and a particular thread is not confined to a single application domain. That is, threads are free to cross application domain boundaries; a new thread is not created for each application domain.

At any given time, every thread executes in an application domain. Zero, one, or multiple threads might be executing in any given application domain. The runtime keeps track of which threads are running in which application domains. You can locate the domain in which a thread is executing at any time by calling the Thread.GetDomain method.

(Taken from https://docs.microsoft.com/en-us/dotnet/framework/app-domains/application-do... )

Below is a simplest testcase to demonstrate how a single-threaded application can have two AppDomains with such a thread running in both domains.

It's also availabel it ideone: https://ideone.com/kUfOND

Regards.

using System; using System.Reflection; using System.Threading;

namespace TestTwoDomainsAndSingeThread { public class Worker : MarshalByRefObject { public void PrintDomain() { Console.WriteLine("Object is executing in AppDomain "{0}"", AppDomain.CurrentDomain.FriendlyName); Console.WriteLine("AppDomain for current thread: " + Thread.GetDomain().FriendlyName); } }

public class Program { static void Main(string[] args) { // Create an ordinary instance in the current AppDomain Worker localWorker = new Worker(); localWorker.PrintDomain();

// Create a new application domain, create an instance // of Worker in the application domain, and execute code // there. AppDomain ad = AppDomain.CreateDomain("New domain"); Worker remoteWorker = (Worker)ad.CreateInstanceAndUnwrap( typeof(Worker).Assembly.FullName, typeof(Worker).FullName); remoteWorker.PrintDomain(); Console.ReadLine(); } } }

-- 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.

WineHQ Bugzilla

10:22 p.m.

https://bugs.winehq.org/show_bug.cgi?id=50849

--- Comment #12 from Bruni earns.61@gmail.com --- I added Console.WriteLine("Current thread ID: " + Thread.CurrentThread.ManagedThreadId.ToString()); at the end of PrintDomain() method to demonstrate the both domains have the same thread ID: https://ideone.com/ACrI9M

...

Object is executing in AppDomain "prog.exe" AppDomain for current thread: prog.exe Current thread ID: 1 Object is executing in AppDomain "New domain" AppDomain for current thread: New domain Current thread ID: 1

-- 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.

WineHQ Bugzilla

13 May 13 May

4:22 p.m.

https://bugs.winehq.org/show_bug.cgi?id=50849

--- Comment #13 from Bruni earns.61@gmail.com --- Test case candidate for comment8 https://ideone.com/VrOQSG Output:

...

VarEnum.VT_R8 name from default domain: VT_R8 Result of (VarEnum)result.vt from another domain: VT_R8 Testcase passed 3.14 value from default domain: 3.14 3.14 value from remote domain: 3.14 Testcase passed Obj value cast: 4614253070214989087 Unwound variant value cast: 4614253070214989087

-- 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.

WineHQ Bugzilla

18 Jun 18 Jun

7:16 p.m.

https://bugs.winehq.org/show_bug.cgi?id=50849

--- Comment #14 from Esme Povirk madewokherd@gmail.com --- I sent a fix upstream: https://github.com/mono/mono/pull/21115

-- 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.

WineHQ Bugzilla

28 Jun 28 Jun

4:38 p.m.

https://bugs.winehq.org/show_bug.cgi?id=50849

--- Comment #15 from Esme Povirk madewokherd@gmail.com --- CI build which includes the fix: https://github.com/madewokherd/wine-mono/actions/runs/972219810

-- 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.

WineHQ Bugzilla

22 Jan 22 Jan

10:05 p.m.

https://bugs.winehq.org/show_bug.cgi?id=50849

--- Comment #16 from Gijs Vermeulen gijsvrm@gmail.com --- This seems to be fixed with wine-7.0, which ships wine-mono 7.0.0.

It was probably fixed by the update to wine-mono 6.3.0 [1], as wine-mono 6.2.1 was the first release to include a fix for this issue according to the changelog.

[1] https://source.winehq.org/git/wine.git/commit/451a54bc7a77b8b816f28ad1c61574...

-- 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.

WineHQ Bugzilla

23 Jan 23 Jan

9:56 a.m.

https://bugs.winehq.org/show_bug.cgi?id=50849

Anastasius Focht focht@gmx.net changed:

--- Comment #17 from Anastasius Focht focht@gmx.net --- Hello Gijs,

--- quote --- It was probably fixed by the update to wine-mono 6.3.0 [1], as wine-mono 6.2.1 was the first release to include a fix for this issue according to the changelog. --- quote ---

https://wiki.winehq.org/Mono#Versions

I've tested it with Wine 6.14 and the installer succeeded (failed with Wine 6.10). So yes, it was fixed by Wine-Mono 6.3.0 upgrade.

Fixed by commit https://source.winehq.org/git/wine.git/commitdiff/451a54bc7a77b8b816f28ad1c6... ("mscoree: Update Wine Mono to 6.3.0.").

Thanks Esme

$ wine --version wine-6.14

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.

WineHQ Bugzilla

28 Jan 28 Jan

8:29 p.m.

https://bugs.winehq.org/show_bug.cgi?id=50849

Alexandre Julliard julliard@winehq.org changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED

--- Comment #18 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 7.1.

-- 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.

1168

Age (days ago)

1479

Last active (days ago)

wine-bugs@winehq.org

18 comments

1 participants

tags (0)

participants (1)

WineHQ Bugzilla