https://bugs.winehq.org/show_bug.cgi?id=48023
Bug ID: 48023 Summary: Visual Studio 2019 not starting Product: Wine Version: 4.18 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: rpisl@seznam.cz Distribution: ---
Created attachment 65561 --> https://bugs.winehq.org/attachment.cgi?id=65561 Hack for RegLoadAppKey
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.
Result: splash screen is shown and then welcome screen is displayed. But after clicking "Not now, maybe later" it halts with:
Application: devenv.exe Framework Version: v4.0.30319 Description: The application requested process termination through System.Environment.FailFast(string message). Message: Failed to schedule time on the UI thread. A continuation would never execute.
It crashes much earlier without the patch/hack as it cannot bind binary registry file and read/create registry keys.
https://bugs.winehq.org/show_bug.cgi?id=48023
Aaron Simmons paleozogt@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |paleozogt@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=48023
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch CC| |fgouget@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #1 from Bruni earns.61@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-c... ---
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.
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #2 from Roman Pišl rpisl@seznam.cz --- Hi Bruni,
- make sure C:\Program Files (x86)\Internet Explorer\ieproxy.dll is in place
I have no ieproxy.dll at that location, there is iexplore.exe only. Is native ie6/7/8 supposed to be installed?
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #3 from Bruni earns.61@gmail.com --- This is strange that Wine64 doesn't create built-in C:\Program Files (x86)\Internet Explorer\ieproxy.dll.
Just try to copy the usual ieproxy.dll from 32-bit wine to that folder.
If it doesn't work, the keys from comment 1 should be rewritten for the 32-bit prefix.
*** Please try instructions for 32-bit wine prefix ***
* 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%\Common Files\Microsoft Shared\MSEnv\msenv100p.dll)
* make sure msenv100p.dll.manifest is located in the following directory C:\Program Files\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}
* make sure the following registry key is in place:
- Computer\HKEY_CLASSES_ROOT\CLSID{A4A1A128-768F-41E0-BF75-E4FDDD701CBA} (It should have a subkey called InProcServer32 and its default value should be C:\Program Files\Internet Explorer\ieproxy.dll
* make sure C:\Program Files\Internet Explorer\ieproxy.dll is in place
* try run VS
https://bugs.winehq.org/show_bug.cgi?id=48023
Lorenzo Ferrillo lorenzofer@live.it changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lorenzofer@live.it
--- Comment #4 from Lorenzo Ferrillo lorenzofer@live.it --- I was able to make the Login UI come on screen, but it hang/close immediatly after. The hang/close seems related to an ACCESS_VIOLATION_EXCPETION being rised, sometimes failing in a seh overflow. Most times the resulting logs is different that seems to suggest that there is an initialization failure that is preventing some threaded operations to run. (For example the SetBlanket, QueryBlanket pair apeared in the log 2 times in 10 runs). Using schedtool -a0 seem to make this better, but still close/hang. +relay traces aren't useful. VS in that case exit with "Some component not found" failing to find some registry keys (in normal +reg log we can see it check for a key in VisualStudio\16.xxxxxx\Packages and then in VisualStudio\16.xxx_Config\Packages, the key being in the second one, while in +relay trace it only check the first location).
Startng devenv seems to trigger a "Unhandled page fault on execute access" in winedevice.exe, then it's trying to start vsjitdebugger.exe (unlcear if it's failing to start it or just can't debug the exception) Remade winedbg the default debugger, still no info appears. (Maybe devenv is changing the protection of some memory page?)
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #5 from Lorenzo Ferrillo lorenzofer@live.it --- Edit it seems that in the current prefix the exception is present whetever I use schedtool -a 0 to launch an application, disregard (but this can be a symptom of another issue, involving maybe dotnet)
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #6 from Lorenzo Ferrillo lorenzofer@live.it --- Created attachment 71911 --> https://bugs.winehq.org/attachment.cgi?id=71911 actctx use build_assembly_dir to assign assembly->dir field
Update: with the latest ncrypt patches from Santino Mazza, the vs WebInstaller can be launched directly without the manual ODT workaround (winetricks d3dcompiler_47 is a prequisite) then installed dotnet472 with winetricks and msxml6 (note for me installing msxml6 before dotnet seems to make dotnet461 and dotnet462 hang with a deadlock, when using gui mode, but it succeeded the time I tried quiet mode, however more testing is required) Selected C++ component in VS installer. Install complete, but the Microsoft.DiagnosticsHub.Collection.StopService.Install give an error "c:\windows\syswow64\sc.exe" stop VSStandardCollectorService150 (return Invalid function) The first start of devenv.exe doesn't work. A devenv.exe.config it's generated and then read from AppData\Local (and not from the Program Files folder) but it's empty. You can see in the ActivityLog.xml a list of not found assemblies, but they are present and installed. This happen becouse actctx doesn't set properly the assembly directory. In another issue on this tracker there is an old patch ,that I have rebased, and attached. A workaround for this is to copy the devenv.exe.config from the deven.exe dir to Appdata\local dir and changing relativeBindForResources to "false" After this passage, the Login UI shows up but: 1) It hangs immediatly and the log spam threads blocked loader and heap CS 2) As 1 but give a warning message about component not loading 3) The program termiate with a runtime termination. 4) Program terminate with a dotnet exception System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. at Microsoft.Internal.VisualStudio.Shell.Interop.IVsPackageManagerPrivate.LoadPackageWithContext(Guid& packageGuid, Int32 reason, Guid& context)
The ActivityLog has some errors: Failed to set Public Key Token 80070057 - E_INVALIDARG Binding Redirect / CodeBase entry from configuration hive is malformed, ignoring. Software\Microsoft\VisualStudio\16.0_0c573400_Config\RuntimeConfiguration\dependentAssembly\codeBase{7E3052B2-FB42-4E38-B22C-1FD281BD4413} 80070057 - E_INVALIDARG Binding Redirect / CodeBase entry from configuration hive is malformed, ignoring. Software\Microsoft\VisualStudio\16.0_0c573400_Config\RuntimeConfiguration\dependentAssembly\codeBase{938D3E45-5067-45C4-9349-5E939A639CBF} 80070057 - E_INVALIDARG (Note these keys doesn't exist in regedit, and Software\Microsoft\VisualStudio\16.0_0c573400_Config is linked to keys that should be written to the privateregistry.bin with RegLoadAppKey. Maybe these keys were supposed to be in the real registry and they are shadowed by the RegLoadAppKey Hack, or they are written to the file in another way ) Failed to find CTMENU resource '#1000' in loaded UI library. Loading UI library {2FFE45C4-5C73-493C-B187-F2E955FF875E} 800a006f Error loading UI library for package Microsoft.VisualStudio.LanguageServices.TypeScript.TypeScriptPackage, Microsoft.VisualStudio.LanguageServices.TypeScript, Version=16.0.0.0, Culture=neutral. HrLoadNativeUILibrary failed with 0x800a006f. SetSite failed for package [Visual Studio Common IDE Package]Source: 'mscorlib' Description: Value cannot be null. Parameter name: type System.ArgumentNullException: Value cannot be null. Parameter name: type at System.Activator.CreateInstance(Type type, Boolean nonPublic) at System.Activator.CreateInstance(Type type) at Microsoft.VisualStudio.CommonIDE.PreviewFeatures.UsePreviewSdk.IsPreviewChannel()
the program also try to load a OLB typelib with TLB_ReadTypeLib in this case dte80a.olb, but it search it in C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE instead of C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\Automation where they are togheter with their manifest.
Note that not all these errors appear every run, it's probably initializing something in mutlithreaded ways, and depending on what run (and fail) before it hang/ crash in different spots.
Note the attached patch seems to solve some errors from ngen.exe Optimization Service during dotnet40 (and following) installation. Not sure if these errors were problematic or not. The {6D5140C1-7436-11CE-8034-00AA006009FA}\ProxyStubClsid32 is {B8DA6310-E19B-11D0-933C-00A0C90DCAA9} (ActXPrxy.dll) not {A4A1A128-768F-41E0-BF75-E4FDDD701CBA} (ieproxy.dll) But replacing them doesn't make any difference. Also in here ActXPrxy.dll is B8DA6310-E19B-11D0-933C-00A0C90DCAA9 not C90250F3-4D7D-4991-9B69-A5C5BC1C2AE6 (non-existant) as in Bruni comment. Other entry mentioned by Bruni are equals.
https://bugs.winehq.org/show_bug.cgi?id=48023
nekoNexus@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nekoNexus@protonmail.ch
https://bugs.winehq.org/show_bug.cgi?id=48023
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |xerox.xerox2000x@gmail.com Ever confirmed|0 |1
--- Comment #7 from Louis Lenders xerox.xerox2000x@gmail.com --- Here`s my five cents of giving it a try:
- Got the same result as Roman from comment #0 after applying his patch.
-After some search for this error on Google I found this thread with no solution, but some interesting start options. Particulary 'wine devenv.exe /resetsettings' makes the GUI come up, but then it hangs (irresponsive GUI) with :
0024:err:sync:RtlpWaitForCriticalSection section 0097022C "?" wait timed out in thread 0024, blocked by 013c, retrying (60 sec )
I was able to trace this back to: 013c:trace:ole:CoWaitForMultipleHandles 0, 0xffffffff, 1, 0220CDF4, 1010EC78 0024:trace:ole:CoGetContextToken context_token 021D47A0 013c:trace:ole:CoWaitForMultipleHandles Waiting for rpc completion
With a dumb hack like in the end of the post, the GUI actually starts, I can quickly click a few things so it`s responsive, but then after a second or three or five the Sign-In window comes up and blocks the application. It says my licence is expired and Sign-up gives me blank window (mshtml insufficiencies I guess). Does anyone know if there`s a trial mode, and how to enable it?
For now it would be interesting: - Find out what difference there is in 'devenv.exe' and 'devenv.exe /resetsettings' - Why that ':CoWaitForMultipleHandles Waiting for rpc completion' never ends. -If the same command on Windows gives the same behaviour (sign-up window which says licence expired)
- I also noticed that the application tries to execute getmac.exe, which is missing from wine, but I don`t know if that`s related to any bug
diff --git a/dlls/combase/rpc.c b/dlls/combase/rpc.c index c51b59de4bf..39cacf15e1b 100644 --- a/dlls/combase/rpc.c +++ b/dlls/combase/rpc.c @@ -1369,6 +1369,7 @@ static HRESULT WINAPI ClientRpcChannelBuffer_SendReceive(LPRPCCHANNELBUFFER ifac struct tlsdata *tlsdata;
TRACE("%p, iMethod %ld\n", olemsg, olemsg->iMethod); +/*Hack*/ if(olemsg->iMethod == 32772) return RPC_E_WRONG_THREAD;
hr = ClientRpcChannelBuffer_IsCorrectApartment(This, apt); if (hr != S_OK)
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #8 from Lorenzo Ferrillo lorenzofer@live.it --- the gui that doesn't come up is for me related to not recognized or badly registerd assemblies. The bad registration happen in the installer, and it seems to stuck into the local application data. In fact deleting and letting devenv regenerate the local data, the gui start as you experience with reset config switch (that I bleieve do the same at this point)
IIRC I don't remember where regenrating it was enought or I had to set relativeBindForResources= false to devenv.exe.config
The registration works for me with the patch I did attach on #6
Thanks for the hack, I'm going to test with it, the actctx patch and the new santino mazza's patchset for registry hives
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #9 from Lorenzo Ferrillo lorenzofer@live.it --- Created attachment 74524 --> https://bugs.winehq.org/attachment.cgi?id=74524 Add Debug Info for IROT CS
Hello.
The Deadlock from the 32772 RPC OLE call, is related to the IROT table, where the log shows what seems a roundtrip to the rpc routines that result in a second call to the IROT during the unmarshalling of the first element from the IROT. This happens on a different thread so it deadlock.
The attached patch restore the debug info for the critical section, it's cleared then that this hang issue is related to this structure.
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #10 from Lorenzo Ferrillo lorenzofer@live.it --- Created attachment 74525 --> https://bugs.winehq.org/attachment.cgi?id=74525 Leave the Critical Section before Unmarhsalling IROT object
Making code leaving the CS before starting the unmarshal of the IROT object resolve the hang, allow wine devenv.exe /resetSettings to have a functioning interface. Allowing to even select a Solution project.
It then Fail Fast on using an unimplemented function in advapi32
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #11 from Lorenzo Ferrillo lorenzofer@live.it --- Created attachment 74527 --> https://bugs.winehq.org/attachment.cgi?id=74527 Add implementation of PerfSetULongCounterValue and PerfSetULongLongCounterValue
With the previous patches, after selecting a solution project it crash on unimplemented advapi32.PerfSetULongCounterValue and after advapi32.PerfSetULongLongCounterValue.
Tried to implement them in the provided patch. It seems to work and go further. (this is always with devenv.exe /resetSettings)
Now it goes a bit further, but still terminate with a Fail Fast exception.
0170:err:eventlog:ReportEventW L"Messaggio: Failed to schedule time on the UI thread. A continuation would never execute.\n" 0170:err:eventlog:ReportEventW L"Stack:\n" 0170:err:eventlog:ReportEventW L" in System.Environment.FailFast(System.String, System.Exception)\n" 0170:err:eventlog:ReportEventW L" in Microsoft.VisualStudio.Services.TaskSchedulerService.VsUIThreadScheduler+<>c.<RequestRpcProcessing>b__6_1(System.Threading.Tasks.Task)\n" 0170:err:eventlog:ReportEventW L" in System.Threading.Tasks.ContinuationTaskFromTask.InnerInvoke()\n" 0170:err:eventlog:ReportEventW L" in System.Threading.Tasks.Task.Execute()\n" 0170:err:eventlog:ReportEventW L" in System.Threading.Tasks.Task.ExecutionContextCallback(System.Object)\n" 0170:err:eventlog:ReportEventW L" in System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)\n" 0170:err:eventlog:ReportEventW L" in System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)\n" 0170:err:eventlog:ReportEventW L" in System.Threading.Tasks.Task.ExecuteWithThreadLocal(System.Threading.Tasks.Task ByRef)\n" 0170:err:eventlog:ReportEventW L" in System.Threading.Tasks.Task.ExecuteEntry(Boolean)\n" 0170:err:eventlog:ReportEventW L" in System.Threading.Tasks.Task.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()\n" 0170:err:eventlog:ReportEventW L" in System.Threading.ThreadPoolWorkQueue.Dispatch()\n" 0170:err:eventlog:ReportEventW L" in System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()\n"
Reason seems to be related to 0154:err:ole:marshal_object Failed to create an IRpcStubBuffer from IPSFactory for {20e8b039-a51a-40c6-8f16-2a8bb99e046f} with error 0x80004002 0154:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x80004002 0154:err:ole:CoMarshalInterface Failed to marshal the interface {20e8b039-a51a-40c6-8f16-2a8bb99e046f}, hr 0x80004002
20e8b039-a51a-40c6-8f16-2a8bb99e046f is IVsInvokableInterface a 4 method interface (Unknown methods + Invoke) This interface doens't exist anywhere in the registry and isn't present in the Automation dlls and their manifests. Tried on a windows laptop with VS installed, it wasn't present there too.
This interface seems to related to the IVsInvokerInterface - 20705D94-A39B-4741-B5E1-041C5985EF61 (seems like this one handle a context switch and invoke the function of a IVsInvokableInterface, but I'm not sure if this analysis is correct), as its asked for when doing some unmarshalling operations on this one.
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #12 from Lorenzo Ferrillo lorenzofer@live.it --- Created attachment 74528 --> https://bugs.winehq.org/attachment.cgi?id=74528 Log +rpc,+ole,+combase,+actctx,+rpcss
Attach the log of the issue (zipped):
0188:trace:actctx:RtlFindActivationContextSectionGuid 00000000 (null) 5 {20e8b039-a51a-40c6-8f16-2a8bb99e046f} 0D70E3EC 0188:trace:ole:create_classes_root_hkey L"\Registry\Machine\Software\Classes" -> 0000106C 0188:warn:ole:CoGetPSClsid No PSFactoryBuffer object is registered for IID {20e8b039-a51a-40c6-8f16-2a8bb99e046f} 0188:warn:ole:marshal_object couldn't get IPSFactory buffer for interface {20e8b039-a51a-40c6-8f16-2a8bb99e046f}
This is where it try to find the interface and fails, it's searching in the registry, but it's not present in there (not even on windows)
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #13 from Nikolay Sivov bunglehead@gmail.com --- Maybe they create contexts dynamically so you won't find this easily in static manifests. Another possibility is that this should actually fail.
IROT fix looks good to me, please consider submitting it.
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #14 from Lorenzo Ferrillo lorenzofer@live.it --- (In reply to Nikolay Sivov from comment #13)
Maybe they create contexts dynamically so you won't find this easily in static manifests. Another possibility is that this should actually fail.
IROT fix looks good to me, please consider submitting it.
How would this context be created and activated? The interface seems actually defined inside Microsoft.VisualStudio.Shell.10.0.dll
I will try submitting the IROT patches upstream
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #15 from Nikolay Sivov bunglehead@gmail.com --- Maybe with CreateActCtx(), if not that, hopefully they use something public to create it. Another possibility is intercepting some Rtl functions, but I don't think there is a reason for that.
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #16 from Lorenzo Ferrillo lorenzofer@live.it --- In that case doesn't the context need to be manually activated? There is a RtlCreateActivationContext call, but I need to look at this more
I see that Microsoft.VisualStudio.Shell.10.0.dll isn't present inside a +module log.
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #17 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Lorenzo Ferrillo from comment #11)
Created attachment 74527 [details] Add implementation of PerfSetULongCounterValue and PerfSetULongLongCounterValue
With the previous patches, after selecting a solution project it crash on unimplemented advapi32.PerfSetULongCounterValue and after advapi32.PerfSetULongLongCounterValue.
Tried to implement them in the provided patch. It seems to work and go further. (this is always with devenv.exe /resetSettings)
Now it goes a bit further, but still terminate with a Fail Fast exception.
Think there might be good news:
I applied pending patch (from Connor McAdams) from the list https://www.winehq.org/mailman3/hyperkitty/list/wine-gitlab@winehq.org/threa... on top of your patches (for ole32 and the PerfSetU*CounterVale) and the patch from comment 1 (for RegLoadAppKey), and now the FailFastException seems to be gone.
I could open a c file and edit it (I did only install CoreIDE) and I didn't need/use the /resetsettings switch. So the GUI of devenv.exe seems to be working at least with these patches.
I'll do some more more testing later to see how far the program gets with other tasks/install more workloads etc.
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #18 from Lorenzo Ferrillo lorenzofer@live.it --- I made the same test and can confirm. I still got a crash (related a NotImplemented call probably related to a QueryBlanket call) but could not figured out why it happened.
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #19 from Lorenzo Ferrillo lorenzofer@live.it --- I'm also getting some unimplemented functions, when trying to open a solution that wasn't opened before: wine: Call from 7B01290D to unimplemented function concrt140.dll.??0_TaskCollection@details@Concurrency@@QAE@XZ, aborting
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #20 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Lorenzo Ferrillo from comment #18)
I made the same test and can confirm. I still got a crash (related a NotImplemented call probably related to a QueryBlanket call) but could not figured out why it happened.
Hi Lorenzo, I saw that yesterday too, but I'm not sure if it was really fatal error.
I have another question really: I reinstalled visual studio (native msxml6) with more components (vs_installer.exe install --channelId VisualStudio.16.Release --channelUri "https://aka.ms/vs/16/release/channel" --productId Microsoft.VisualStudio.Product.Community --add Microsoft.VisualStudio.Workload.NativeDesktop;includeRecommended --quiet) and now I'm getting the old problem again: a window that tells me that my license has expired.
I didn't see that yesterday, so do you have any idea to get around this? I thought Community has trial period of 30 days and is free anyway. I also logged in into my Microsoft account but it tells me updated license couldn't be downloaded. So stuck again for now, you have any idea how to work around this?
Side-note: yet another unimplemented function crash when I click "Create new account": wine: Call from 7B0117A7 to unimplemented function SHELL32.dll.SHAssocEnumHandlersForProtocolByApplication, aborting
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #21 from Lorenzo Ferrillo lorenzofer@live.it --- Not sure,never happened to me, maybe a component need the account registered?
Do you think a SHAssocEnumHandlersForProtocolByApplication stub would work? Or if SHAssocEnumHandlers was implemented maybe it can share part of the functionality
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #22 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Lorenzo Ferrillo from comment #21)
Not sure,never happened to me, maybe a component need the account registered?
Do you think a SHAssocEnumHandlersForProtocolByApplication stub would work? Or if SHAssocEnumHandlers was implemented maybe it can share part of the functionalitye
I have no idea yet. I could look into this later, but point is I have a Microsoft account, so i don't need to create one really. I'll look into this next weekend if you don't beat me, as I don't have access to this machine during week.
Meanwhile at least I got a success: I was able to compile simple Hello World console app by just unplugging my ethernet wire cable after the "license expired " window appeared: I just clicked the "Exit Visual Studio" button, but the GUI stayed alive and responsive for enough time to select and execute the "Build solution " menu item and the Hello World was successfully built
I think this is now very close to basic working; please report any new findings and thanks for your work on this. I'll do more testing next weekend
Regards
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #23 from Lorenzo Ferrillo lorenzofer@live.it --- Created attachment 74775 --> https://bugs.winehq.org/attachment.cgi?id=74775 Partial Implement SHAssocEnumHandlersForProtocolByApplication
This replicate for SHAssocEnumHandlersForProtocolByApplication the functionality of SHAssocEnumHandlers when in the riid arguments is IID_IEnumAssocHandlers, returning a stubbed IEnumAssocHandlers object with the next method stubbed.
This is enough to suppress the exception when asking to create a new account. (it open a browser page)
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #24 from Lorenzo Ferrillo lorenzofer@live.it --- Regarding the login part. There seems to be a lot of unimplemented stuffs either in ieframe and in other internet related components (urlmon,wininet, winsock,etc) I tryed to install ie8 using winetricks, but to no avail. Seems some native internet component, wininet for example, require a function that isn't implemented in builtin urlmon
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #25 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Lorenzo Ferrillo from comment #24)
Regarding the login part. There seems to be a lot of unimplemented stuffs either in ieframe and in other internet related components (urlmon,wininet, winsock,etc)
Instead of "use embedded browser" you can select "use systembrowser" in the window that comes up under option "settings" or something like that (forgot exact naming).
Anyway, it means this bug has luckily an easy workaround
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #26 from Lorenzo Ferrillo lorenzofer@live.it --- Can confirm that the system browser workaround works correctly and can associate multiple accounts.
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #27 from Lorenzo Ferrillo lorenzofer@live.it --- using native concrt140 seems to solve the unimplemented function error, and correct the last problematic functionality on project load
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #28 from Lorenzo Ferrillo lorenzofer@live.it --- Created attachment 74787 --> https://bugs.winehq.org/attachment.cgi?id=74787 Working compilation
Compilation of a multi project solution, with C++ and inline assembly, with Dark Theme. Code reside outside the wine prefix structure.
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #29 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Lorenzo Ferrillo from comment #28)
Created attachment 74787 [details] Working compilation
Compilation of a multi project solution, with C++ and inline assembly, with Dark Theme. Code reside outside the wine prefix structure.
Very nice and cool! Gonna try this too this weekend; Would you mind sharing how you exactly installed the program? Maybe issue I ran into (the window that tells me the license expired) has to do with the way I installed it (?)
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #30 from Louis Lenders xerox.xerox2000x@gmail.com --- For anyone who also runs into this "license has expired" blocking window: Somehow I managed to solve this by doing things found on the internet.
- Removed a few regkeys: https://stackoverflow.com/questions/31725192/visual-studio-2015-prerelease-s...
(I don't know if this really needed)
- Make sure I was signed out of my account
- Start the installer again (vs_community) and choose the option "repair"
(all this is done with native msxml6)
devenv.exe now works rather stable (also used native concrt140) , compiled simple project. I encountered another fatal Failfastexception two times, which seemed related to UI issues, so for now I run with LIBGL_ALWAYS_SOFTWARE=1 which seems to make it more stable for me (again, not 100% sure about this, needs more testing)
All this is done while I'm not signed in. I'll try sign in and see how things go then.
About this bugreport: It now contains lot of info. Guess we need to split out seperate issues.
The issue "Visual Studio not starting" basically only needs 3 patches
1. RegLoadAppKey patch https://bugs.winehq.org/attachment.cgi?id=65561&action=diff Attempt
An attempt was done by Santino Mazzo https://gitlab.winehq.org/wine/wine/-/merge_requests/820 but never made it upstream.
2. Patch https://bugs.winehq.org/attachment.cgi?id=74525&action=diff Nicolai said it looked ok, so hopefully Lorenzo: you might wanna try to get this upstream?
3. Pending patch on the list https://www.winehq.org/mailman3/hyperkitty/list/wine-gitlab@winehq.org/threa...
This patch is linked to bug https://bugs.winehq.org/show_bug.cgi?id=54609
All the other patches are for actually working with the program so guess we should track these issues in new bugreports, once the above issues are solved
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #31 from Lorenzo Ferrillo lorenzofer@live.it --- In some cases when upgrading solutions (maybe only when the conversion got errors or warnings), the ide can crash when trying to open inside the UpgradeLog.html.
native msimtf.dll and ieframe.dll are workarounds
https://bugs.winehq.org/show_bug.cgi?id=48023
F H francisco278herrera@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |francisco278herrera@gmail.c | |om
--- Comment #32 from F H francisco278herrera@gmail.com --- Issue is still present in wine 9.21; visual studio doesn't start due to lack of custom registry hive support on wine. merge request for this https://gitlab.winehq.org/wine/wine/-/merge_requests/820 is still a work in progress
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #33 from F H francisco278herrera@gmail.com --- Sorry I meant it still happens when trying to install visual studio 2022 community
https://bugs.winehq.org/show_bug.cgi?id=48023
Mads mads@ab3.no changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mads@ab3.no
https://bugs.winehq.org/show_bug.cgi?id=48023
--- Comment #34 from F H francisco278herrera@gmail.com --- (In reply to F H from comment #33)
Sorry I meant it still happens when trying to install visual studio 2022 community
For more details please see the AppDB entry https://appdb.winehq.org/objectManager.php?sClass=version&iId=42073
-
WineHQ Bugzilla