[Bug 48023] Visual Studio 2019 not starting
WineHQ Bugzilla
wine-bugs at winehq.org
Thu Nov 18 13:43:41 CST 2021
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #1 from Bruni <earns.61 at gmail.com> ---
Hi Roman!
>After https://bugs.winehq.org/show_bug.cgi?id=47626 just out of curiosity I tried running
>Visual Studio: winetricks corefonts dotnet472 msxml6 and applied the attached patch/hack.
>Message: Failed to schedule time on the UI thread. A continuation would never execute.
Out of curiosity, I managed to make Visual Studio 2019 crash on Windows 7x64
with the same message ("Failed to schedule time on the
UI thread. A continuation would never execute.") just by changing specific
registry key from default value to wrong one, since
Visual Studio is very picky about registry keys.
Specifically, I changed the following key from
Computer\HKEY_CLASSES_ROOT\Wow6432Node\Interface{6D5140C1-7436-11CE-8034-00AA006009FA}\ProxyStubClsid32
(Standard) REG_SZ {A4A1A128-768F-41E0-BF75-E4FDDD701CBA}
to
Computer\HKEY_CLASSES_ROOT\Wow6432Node\Interface{6D5140C1-7436-11CE-8034-00AA006009FA}\ProxyStubClsid32
(Standard) REG_SZ {C90250F3-4D7D-4991-9B69-A5C5BC1C2AE6}.
Then VS started crashing.
After I have changed it back to {A4A1A128-768F-41E0-BF75-E4FDDD701CBA}, Visual
Studio 2019 started working again.
In short words, Visual Studio 2019 on Windows 7 wants IServiceProvider in
registry to be ieproxy.dll ({A4A1A128-768F-41E0-BF75-
E4FDDD701CBA}), not ActXPrxy.dll ({C90250F3-4D7D-4991-9B69-A5C5BC1C2AE6}) which
is default in all Wine versions. Visual Studio
running on a specific Windows version wants a specific IServiceProvider in
registry (as it seems, Windows 10 has
OneCoreCommonProxyStub.dll as the default IServiceProvider; Wine lacks this
dll).
Another possible reason for this bug (for initial start while looking for
Interface{6D5140C1-7436-11CE-8034-00AA006009FA}) is the
bug 41713: wine doesn't have its registry fully populated in some cases.
Below is an investigation from Microsoft site, stating there must be a number
of registry keys in place for VS 2019 to start.
Roman, could you try the following, please, to see if VS starts on your end?
* run `rm -rf ~/.wine && ./wine hostname && ./server/wineserver -w` before
doing anything to prevent registry from not being fully
populated (see bug 41713)
* Set Windows 7 as OS in winecfg (Windows 10 is not a working option since wine
lacks OneCoreCommonProxyStub.dll as the default
IServiceProvider in this windows version)
* run `./wine regsvr32 "%ProgramFiles%\Internet Explorer\ieproxy.dll"`
* install VS 2019 with the hack from comment 0 BUT DON'T RUN IT
* make sure the following registry keys are in place:
-
Computer\HKEY_CLASSES_ROOT\Interface{20705D94-A39B-4741-B5E1-041C5985EF61} (It
should have a subkey called ProxyStubClsid32
and its default value should be {2C28A1A9-EDB1-4A70-AE14-E0A5C7E81C2C})
- Computer\HKEY_CLASSES_ROOT\CLSID{2C28A1A9-EDB1-4A70-AE14-E0A5C7E81C2C}
(it should have a subkey called InProcServer32 and its
default value should be %ProgramFiles(x86)%\Common Files\Microsoft
Shared\MSEnv\msenv100p.dll)
* make sure msenv100p.dll.manifest is located in the following directory
C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\Common7\IDE\Automation
,
and contains the following entry inside
<comInterfaceExternalProxyStub name=“IVsInvokerPrivate”
iid=“{20705D94-A39B-4741-B5E1-041C5985EF61}” numMethods=“4”
proxyStubClsid32=“{2C28A1A9-EDB1-4A70-AE14-E0A5C7E81C2C}”/>
* make sure the following registry keys are in place:
-
Computer\HKEY_CLASSES_ROOT\Interface{6D5140C1-7436-11CE-8034-00AA006009FA} (It
should have a subkey called ProxyStubClsid32
and its default value should be {A4A1A128-768F-41E0-BF75-E4FDDD701CBA}
-
Computer\HKEY_CLASSES_ROOT\Wow6432Node\Interface{6D5140C1-7436-11CE-8034-00AA006009FA}
(It should have a subkey called
ProxyStubClsid32 and its default value should be
{A4A1A128-768F-41E0-BF75-E4FDDD701CBA}
* make sure the following registry key is in place:
-
Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID{A4A1A128-768F-41E0-BF75-E4FDDD701CBA}
(It should have a subkey called
InProcServer32 and its default value should be C:\Program Files (x86)\Internet
Explorer\ieproxy.dll
* make sure C:\Program Files (x86)\Internet Explorer\ieproxy.dll is in place
* try to run it in usual way you used in comment 0 (VS 2019 should start)
--- short remark ---
(Microsoft tends to sporadically remove useful content (or move it to hardly
findable places). It seems
https://developercommunity2.visualstudio.com/t/ defies caching connections from
web.archive.org. Every time I try to archive
something from that Microsoft's tricky site by means of web archive I get an
infinitely loading ring. So I had nothing better to do
but to just copy key posts from there right to Wine Bugzilla.)
--- end of short remark ---
Visual Studio 2019 Crashes at Startup with error: "Failed to schedule time on
the UI thread.
A continuation would never execute."
As it turned out, Visual Studio 2019 refuses to start if there is no CLSID of
COM proxy for IServiceProvider in registry.
They managed to fix it with adding certain keys in registry to make Visual
Studio see CLSID of the COM provider to be used.
--- quote from
https://developercommunity2.visualstudio.com/t/Visual-Studio-2019-IDE-will-closed-autom/1315572
---
> Closed - Fixed
> Visual Studio 2019 IDE will closed automatically after starting it after 5 seconds
> The VS2019 IDE is only runs stable if I start the VS2019 IDE in administration mode.
> But in the user mode it will close after 5 seconds.
> Please support me.
> HaJo
> --------------------------------------------------------------------------------------
> Pinned
> Microsoft Solution - Ryan Molden [MSFT] Closed - Fixed
> Both instances of this have been determined to be incorrect registry entries on the users machines
> around the COM proxy for IServiceProvider. Both users have had the issue resolved
> (one by a windows repair and the other by manually repairing the registry).
> Ryan Molden
> Software Engineer
> Microsoft Visual Studio Performance and Reliability Team
> --------------------------------------------------------------------------------------
>Calvin Hsia [MSFT]
Hi Hans-Joachim
Sorry for the late response: this issue was assigned to a team member who
became busy with other tasks.
I understand that VS works fine for you in Admin mode, but seems to close/crash
after a few seconds in user mode?
It’s strange that running as Admin is different.
Did you already try to create another user account (non-admin) and run VS from
it?
Do you have access to another machine on which to try the scenario?
There is a clue from the .Net Event log (right-click on start button,
EventViewer, Windows Logs->Application)
It indicates that a task couldn’t be scheduled and thus FailFast was called
(which quickly terminates the process as a crash)
Understanding the details of what task was failing and why can come from a 32
bit dump.
The eventlog will typically record most crash events.
Event Time (UTC): 13.01.2021 18:49:31
Event ID: 1025
Data: Anwendung: devenv.exe
Frameworkversion: v4.0.30319
Beschreibung: Die Anwendung forderte die Beendigung des Prozesses durch
System.Environment.FailFast(Zeichenfolgenmeldung) an.
Meldung: Failed to schedule time on the UI thread. A continuation would never
execute.
Stapel:
bei System.Environment.FailFast(System.String, System.Exception)
bei
Microsoft.VisualStudio.Services.TaskSchedulerService.VsUIThreadScheduler+<>c.<RequestRpcProcessing>b__6_1
(System.Threading.Tasks.Task)
bei System.Threading.Tasks.ContinuationTaskFromTask.InnerInvoke()
bei System.Threading.Tasks.Task.Execute()
bei System.Threading.Tasks.Task.ExecutionContextCallback(System.Object)
bei
System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext,
System.Threading.ContextCallback,
System.Object, Boolean)
bei System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext,
System.Threading.ContextCallback, System.Object,
Boolean)
bei
System.Threading.Tasks.Task.ExecuteWithThreadLocal(System.Threading.Tasks.Task
ByRef)
bei System.Threading.Tasks.Task.ExecuteEntry(Boolean)
bei
System.Threading.Tasks.Task.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
bei System.Threading.ThreadPoolWorkQueue.Dispatch()
bei System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
Apr 05, 2021
> --------------------------------------------------------------------------------------
Ryan Molden [MSFT]
···
Hello, have you tried running the Repair option on visual studio? I looked at
the dump and it appears that no COM proxy dlls are
loaded in VS, which is a very strange situation, and would definitely cause
failures here. I can’t explain why your Admin account
would work, unless your normal user account and admin account are actually
DIFFERENT accounts (i.e. you aren’t simply elevating
your normal user account to admin but in fact signing in to a DIFFERENT account
that is admin).
I could write some rather complicated instructions on validating/refreshing the
proxy registration, but it may be easiest to just
try a repair option as it is something that should ‘just work’.
Ryan Molden
Software Engineer
Microsoft Visual Studio Performance and Reliability Team
May 10, 2021
> --------------------------------------------------------------------------------------
Ryan Molden [MSFT]
···
Sorry for the delay, I have been wrapped up in other work tasks/ having some
outside of work stuff that has taken my time. These
kind of COM registration issues can be pretty ugly to figure out. First thing
is to verify you have the right registration, to
start verify you have this key in the registry
HKEY_CLASSES_ROOT\Interface{20705D94-A39B-4741-B5E1-041C5985EF61}
It should have a subkey called ProxyStubClsid32 and its default value should be
{2C28A1A9-EDB1-4A70-AE14-E0A5C7E81C2C}
You should also have this key in the registry
HKEY_CLASSES_ROOT\CLSID{2C28A1A9-EDB1-4A70-AE14-E0A5C7E81C2C}
and it should have a subkey called InProcServer32 and its default value should
be
%ProgramFiles(x86)%\Common Files\Microsoft Shared\MSEnv\msenv100p.dll
Are both of these keys present?
Ryan Molden
Software Engineer
Microsoft Visual Studio Performance and Reliability Team
Jun 11, 2021
> --------------------------------------------------------------------------------------
Paul Mullin
···
Ryan, after checking, I do not have that first Key in the Registry
Interface{(20705D94-A39B-4741-B5E1-041C5985EF61)}
Jun 11, 2021
> --------------------------------------------------------------------------------------
Paul Mullin
···
I do not have the second Key either…
(HKEY_CLASSES_ROOT\CLSID{2C28A1A9-EDB1-4A70-AE14-E0A5C7E81C2C})
Jun 11, 2021
> --------------------------------------------------------------------------------------
Ryan Molden [MSFT]
···
Sorry for not being a bit more informative in my ‘check the registry’ response,
but it seems you did manage to figure out the
approach. Them not being in the registry is odd (I believe, we have
recently(ish) moved to registration-free COM so it may no
longer be necessary, not entirely 100% on that).
Can you look in your VS install directory, under Common7\Automation, look for a
file called msenv100p.dll.manifest and see if that
file has the 20705D94-A39B-4741-B5E1-041C5985EF61 GUID in it?
Ryan Molden
Software Engineer
Microsoft Visual Studio Performance and Reliability Team
Jun 11, 2021
> --------------------------------------------------------------------------------------
Hans-Joachim Ehlers
···
Hello Ryan Molden
I see that another people Paul Mullin has the same Problem like me.
But I have the following results to your question to Paul.
Hans-Joachim Ehlers
First question
The following key is not inside my registry
HKEY_CLASSES_ROOT\Interface{20705D94-A39B-4741-B5E1-041C5985EF61}
The following key is not inside my registry
HKEY_CLASSES_ROOT\CLSID{2C28A1A9-EDB1-4A70-AE14-E0A5C7E81C2C}
That means no key is present !!!
Second question
The following directory doesn’t exist
Common7\Automation
I see only the following directorys
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\Packages
C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\Common7\ServiceHub
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\Tools
But your requested file
msenv100p.dll.manifest
is located in the following directory
C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\Common7\IDE\Automation
In this file the following entry is inside
<comInterfaceExternalProxyStub name=“IVsInvokerPrivate”
iid=“{20705D94-A39B-4741-B5E1-041C5985EF61}” numMethods=“4”
proxyStubClsid32=“{2C28A1A9-EDB1-4A70-AE14-E0A5C7E81C2C}”/>
Is this OK ?
What are the next steps ?
Jun 12, 2021
> --------------------------------------------------------------------------------------
Ryan Molden [MSFT]
···
Sorry, yes my directory listed was off (omitted the IDE subdir before
Automation). Okay, it looks like the registry data is
probably entirely contained inside that manifest, which explains why it isn’t
in the global registry.
So now we have to figure out why it doesn’t seem to be loading / finding the
proxy dlls which prevents VS from starting…
Two potential ways to get more info
SxsTrace:
1: Run sxstrace Trace -logfile:sxstrace.etl
2: Launch devenv
3: Run sxstrace Parse -logfile:sxstrace.etl -outfile:sxstrace.txt
The output in the sxstrace.txt may (or may not) be interesting to helping us
understand if there was some problem during the
processing of the manifest.
Windbg:
1: Download and install Windbg if you don’t already have it
(https://docs.microsoft.com/en-us/windows-
hardware/drivers/debugger/debugger-download-tools)
2: Run gflags.exe from the install directory from an admin command prompt
3: Select the Image File tab in the UI
4: Enter devenv.exe and hit tab (should enable all the options in the lower
window section)
5: Select Show Loader Snaps in the first group of options at the top (and click
Apply)
6: Launch windbg
7: File -> Open Executable
8: Point it at devenv.exe from your VS install directory
9: Hit F5
10: Copy the voluminous spew from the output window in Windbg after VS gets
done running/shutting down
11: Attach the data from the Windbg window here
12: Go back to gflags and uncheck Show Loader Snaps
Ryan Molden
Software Engineer
Microsoft Visual Studio Performance and Reliability Team
Jun 13, 2021
> --------------------------------------------------------------------------------------
Ryan Molden [MSFT]
···
Yes, I was still looking through your log, but didn’t see anything that stood
out, other than the FailFast, but already knew that
was happening. I think the next step, and the ‘big hammer’, is to collect a
time-travel trace. It should be feasible since VS
doesn’t get far in startup.
If you look in your Windbg install directory I believe there should be a TTD
subdirectory, in that there should be a TTTracer.exe
program. If you launch that with
TTTracer.exe -launch <path to Visual Studio> -out <directory path to store data
in>
and zip up everything that ends up in <directory path to store data in>, then I
should be able to dig further.
Ryan Molden
Software Engineer
Microsoft Visual Studio Performance and Reliability Team
Jun 28, 2021
> --------------------------------------------------------------------------------------
Hans-Joachim Ehlers
···
Hello Ryan
I not found a programm like TTTracer. Here is a list which programm are in the
directory.
Maybe another programm make the same. In the other case I need a installation
for this tool.
Suchergebnis_29_06_2021__15_06_15.txt
HaJo
Jun 29, 2021
> --------------------------------------------------------------------------------------
Ryan Molden [MSFT]
···
Hmm, I thought they shipped it with normal Windbg install, it may be an option
if you open the installer and choose ‘Repair’ or
‘Modify’ (not sure what the option would be called) and look for Time Travel
Debugging in the list of optional features to install.
If not, you can try installing Wndbg Preview from the store as this MSDN bit
talks about: https://docs.microsoft.com/en-
us/windows-hardware/drivers/debugger/time-travel-debugging-overview#ttd-availability
Ryan Molden
Software Engineer
Microsoft Visual Studio Performance and Reliability Team
Jun 29, 2021
> --------------------------------------------------------------------------------------
Hans-Joachim Ehlers
···
Hello Ryan
I had found the tracer and the starting works only with the following line
(without -out parameter)
C:\Downloads\VisualStudio_2019\Test2>C:\Windows\SysWOW64\tttracer.exe -launch
“C:\Program Files (x86)\Microsoft Visual Studio
\2019\Enterprise\Common7\IDE\devenv.exe”
Launching ‘“C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\Common7\IDE\devenv.exe”’
devenv.exe(x86) (PID:9108): Process exited with exit code -805306369 after
1405828ms
Full trace dumped to C:\Downloads\VisualStudio_2019\Test2\devenv01.run
But if I run the VS in the tracer the created file is > 20 GByte and VS runs so
much slowly. The other point is that the crash
seams that not occurs in this mode. This is the reason why I can deliver a
trace file.
Sorry but the tracer repair the failure.
HaJo
Jun 29, 2021
> --------------------------------------------------------------------------------------
Ryan Molden [MSFT]
···
Darn, sometimes tracing can affect the timing. Could you try what they suggest
in this article:
https://mskb.pkisolutions.com/kb/983279 (sadly I can’t find the official MS KB
for this, but this web site just mirrors what the KB
said anyways, I can validate that since I worked on this problem originally). I
believe the file you want to register is Windows
\System32\OneCoreCommonProxyStub.dll, but if that doesn’t exist try one of the
other two in the article (assuming they exist).
Ryan Molden
Software Engineer
Microsoft Visual Studio Performance and Reliability Team
Jun 30, 2021
> --------------------------------------------------------------------------------------
Hans-Joachim Ehlers
···
Hello Ryan,
the files form the Internet-Page are not in my system
C:\WINDOWS\system32>dir “c:\Program Files\Internet Explorer*.dll”
Datentrager in Laufwerk C: ist ACER
Volumeseriennummer: CEFA-DBA1
Verzeichnis von c:\Program Files\Internet Explorer
07.12.2019 11:09 54.784 hmmapi.dll
07.12.2019 11:09 421.888 IEShims.dll
07.12.2019 11:09 48.536 sqmapi.dll
3 Datei(en), 525.208 Bytes
0 Verzeichnis(se), 459.880.722.432 Bytes frei
C:\WINDOWS\system32>dir “c:\Program Files (x86)\Internet Explorer*.dll”
Datentrager in Laufwerk C: ist ACER
Volumeseriennummer: CEFA-DBA1
Verzeichnis von c:\Program Files (x86)\Internet Explorer
07.12.2019 11:10 50.176 hmmapi.dll
07.12.2019 11:10 315.392 IEShims.dll
07.12.2019 11:10 40.232 sqmapi.dll
3 Datei(en), 405.800 Bytes
0 Verzeichnis(se), 459.881.177.088 Bytes frei
But the files from you describtion was found on my system but
if I try to register it I get an failure.
C:\WINDOWS\system32>dir c:\Windows\System32\OneCoreCommonProxyStub.dll
Datentrager in Laufwerk C: ist ACER
Volumeseriennummer: CEFA-DBA1
Verzeichnis von c:\Windows\System32
16.04.2021 21:09 493.056 OneCoreCommonProxyStub.dll
1 Datei(en), 493.056 Bytes
0 Verzeichnis(se), 459.884.199.936 Bytes frei
C:\WINDOWS\system32>regsvr32 “c:\Windows\System32\OneCoreCommonProxyStub.dll”
==============> I had try it but it delivers the following failure
VisualC_RegisterFailure.jpg
Jul 01, 2021
> --------------------------------------------------------------------------------------
Hans-Joachim Ehlers
···
Hello Ryan
the regsvr32
C:\WINDOWS\system32>regsvr32 “c:\Windows\System32\OneCoreCommonProxyStub.dll”
delivery a failure (see my comment from 01.07.2021) but if I try the tool
“RegDllView.exe” the
dll seams to be registered.
RegDllViewer.jpg
Jul 04, 2021
> --------------------------------------------------------------------------------------
Ryan Molden [MSFT]
···
Can you look up the following two keys in your registry and tell me what they
have for their default value?
HKEY_CLASSES_ROOT\Interface{6D5140C1-7436-11CE-8034-00AA006009FA}\ProxyStubClsid32
HKEY_CLASSES_ROOT\WOW6432Node\Interface{6D5140C1-7436-11CE-8034-00AA006009FA}\ProxyStubClsid32
Ryan Molden
Software Engineer
Microsoft Visual Studio Performance and Reliability Team
Jul 06, 2021
> --------------------------------------------------------------------------------------
Hans-Joachim Ehlers
···
Hello Ryan
here are the results.
HaJo
Computer\HKEY_CLASSES_ROOT\Interface{6D5140C1-7436-11CE-8034-00AA006009FA}\ProxyStubClsid32
Name Typ Daten
(Standard) REG_SZ {A6FF50C0-56C0-71CA-5732-BED303A59628}
Computer\HKEY_CLASSES_ROOT\Wow6432Node\Interface{6D5140C1-7436-11CE-8034-00AA006009FA}\ProxyStubClsid32
Name Typ Daten
(Standard) REG_SZ {C90250F3-4D7D-4991-9B69-A5C5BC1C2AE6}
Jul 07, 2021
> --------------------------------------------------------------------------------------
Ryan Molden [MSFT]
···
Interesting, the entry for the first one looks right (i.e. matches mine), the
second one does not. Can you tell me what this entry
has for its default value?
HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{C90250F3-4D7D-4991-9B69-A5C5BC1C2AE6}\InProcServer32
Ryan Molden
Software Engineer
Microsoft Visual Studio Performance and Reliability Team
Jul 07, 2021
> --------------------------------------------------------------------------------------
Hans-Joachim Ehlers
···
Hello Ryan
there is no default value. There are two other once
Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID{C90250F3-4D7D-4991-9B69-A5C5BC1C2AE6}\InProcServer32
(Standard) REG_SZ C:\Windows\SysWOW64\ActXPrxy.dll
ThreadingModel REG_SZ Both
Jul 08, 2021
> --------------------------------------------------------------------------------------
Ryan Molden [MSFT]
···
Can you try changing this entry
Computer\HKEY_CLASSES_ROOT\Wow6432Node\Interface{6D5140C1-7436-11CE-8034-00AA006009FA}\ProxyStubClsid32
Name Typ Daten
(Standard) REG_SZ {C90250F3-4D7D-4991-9B69-A5C5BC1C2AE6}
to make the (Standard) value the same as the non WOW6432 node? So make it
{A6FF50C0-56C0-71CA-5732-BED303A59628}?
Ryan Molden
Software Engineer
Microsoft Visual Studio Performance and Reliability Team
Jul 08, 2021
> --------------------------------------------------------------------------------------
Ryan Molden [MSFT]
···
You can try changing it, both the Wow6432 and non-Wow6432 node should match, so
changing them to match is not problematic.
Ryan Molden
Software Engineer
Microsoft Visual Studio Performance and Reliability Team
Jul 08, 2021
> --------------------------------------------------------------------------------------
Hans-Joachim Ehlers
···
Hello Ryan
now I had change the following value from
Computer\HKEY_CLASSES_ROOT\Wow6432Node\Interface{6D5140C1-7436-11CE-8034-00AA006009FA}\ProxyStubClsid32
Name Typ Daten
(Standard) REG_SZ {C90250F3-4D7D-4991-9B69-A5C5BC1C2AE6}
to
Computer\HKEY_CLASSES_ROOT\Wow6432Node\Interface{6D5140C1-7436-11CE-8034-00AA006009FA}\ProxyStubClsid32
Name Typ Daten
(Standard) REG_SZ {A6FF50C0-56C0-71CA-5732-BED303A59628}
And it seams that the VS works in the user mode.
HaJo
Jul 08, 2021
--- end of quote ---
So it looks like VS 2019 is very sensitive to registry corruption.
OneCoreCommonProxyStub.dll is the new IServiceProvider interface for Windows 10
and it is not present in Wine so far.
--
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.
More information about the wine-bugs
mailing list