| Author |
 Topic  |
|
|
NafetsPB
Junior Member
Germany
22 Posts |
 Posted - Jul 30 2018 : 02:06:21 AM
|
I just did an upgrade from 2270.0 to 2283.1 for my Visual Studio Enterprise 2017 installation (latest version 15.7.5). To do so, I closed VS and started the VA installer. When it reported "installation complete" I started VS again with the previous solution.
Directly after opening the solution, however, Visual Studio stopped responding and closed itself. I tried to start it three times without success.
Then I started the installer of 2270.0 again to revert back. After doing so, VS started without problems, using version 2270.0 as expected. I then tried another install: While VS was running, I started the VA 2283.1 installer, and while it tried to install (it reported "retrying...") I quit my instance of Visual Studio.
After a while it reported "installation complete" and now VS seems to work with 2283.1 activated (no further crashes as of now).
Did anyone observe a similar behavior? I'm reluctant to recommend the upgrade to my co-workers because of this until I figured out what might have caused it... |
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
|
|
NafetsPB
Junior Member
Germany
22 Posts |
Posted - Jul 30 2018 : 04:49:10 AM
|
quote:
Originally posted by accord
This is strange and should not happen. Hopefully, this was a one-off problem. If this happens for any other co-worker, saving a mini-dump of the crash might help:
It is now happening again with another solution. However, it seems to me that the application (VS) just quits somehow and does not "really" crash.
Additionally, it only seems to happen when I open VS directly with the solution in question (using the shortcuts that the VS icon provides in the windows task bar). If I start VS without a solution and then use the "open recent solution" command it works fine. Once that is done it continues to work when opened directly with the solution.
Furthermore the instance seems to run fine when I attach a debugging instance to the VS process in question.
With an attached debugging instance VS opens the solution and does not quit (at least not immediately; it starts parsing files in the solution). As soon as I start it without the attached debugging instance it stops working again (when opening it directly with the solution on startup).
Strange... So it seems as if the problem only appears when you open VS directly with a solution that has not yet been opened with the latest version of VA; once the solution has been parsed by the lastest version of VA (by using "open recent solution") it can be opened directly again from that point on forward.
I will try to get you that minidump somehow if I can get it to "crash" when the debugger is attached. However, right now I do not see a way how...
|
 |
|
|
astypalaia
New Member
Russia
3 Posts |
Posted - Jul 30 2018 : 05:21:48 AM
|
| The similar problem with VS 15.7.5 and VA 2283.1. When i start VS after upgrade VA, VA shows me dialog with keyboard shortcuts. And in the same moment crashes saying something about VA plugin. Reinstall 2270 - everything is fine. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Jul 30 2018 : 06:25:58 AM
|
So far I cannot reproduce either problem, so it looks like there is something specific at work here, now we just need to try and find out what that something is.
There are a couple of things to try, if either of you have the time. First, turn on VA logging before loading the IDE. If we are lucky this will tell us something useful before the crash stops the logging. To do this open regedit and set the registry key:
HKCU\Software\Whole Tomato\Logging = 1
and now load the IDE, reproducing the problem. This page explains where the log files will be written to:
https://docs.wholetomato.com/default.asp?W305
The other approach is to tell Windows Error Reporting to save out a mini dump file when the IDE crashes. This is explain here:
https://docs.wholetomato.com/default.asp?W303#wer
Please send any logs and minidump files to us via the form:
http://www.wholetomato.com/support/contact.asp
including this thread ID or URL in the description, so we can match it up. |
zen is the art of being at one with the two'ness |
|
|
|
astypalaia
New Member
Russia
3 Posts |
Posted - Jul 30 2018 : 09:03:42 AM
|
Send dump, logs, ActivityLog.xml and picture with
technical request case number is 118020 |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Jul 30 2018 : 10:48:23 AM
|
I have the files, thank you. Based on the error message about "VaDebuggerToolsPackage package did not load correctly" can you please try disabling VA in the dialog:
IDE tools menu -> Extensions and Updates...
this will require an IDE restart. Can you then go back into this dialog again, and Enable VA, which will require a second IDE restart. I don't know if this will help, but it is a fairly quick test, which is something. |
zen is the art of being at one with the two'ness |
|
|
|
astypalaia
New Member
Russia
3 Posts |
Posted - Jul 30 2018 : 11:36:13 AM
|
| Disabling VA from IDE tools menu will be a little bit difficult to do: IDE crashes in couple of seconds after start. Just now I rolled back to 2270 and quite happy with it :) |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Jul 30 2018 : 9:22:47 PM
|
@astypalaia I responded via the support system.
@NafetsPB Are you seeing the VA Keybindings dialog being displayed or any package load error messages from VS? When VS starts up (without loading a solution), are any VA Toolwindows open? |
|
|
|
NafetsPB
Junior Member
Germany
22 Posts |
Posted - Jul 31 2018 : 02:05:44 AM
|
quote:
Originally posted by sean
@NafetsPB Are you seeing the VA Keybindings dialog being displayed or any package load error messages from VS? When VS starts up (without loading a solution), are any VA Toolwindows open?
No, I don't see any VA dialogs being displayed or any package load error messages from VS. The status line says something about "Initializing..." and then VS closes itself without any error messages.
Interestingly, though, the issue disappears, at least for a specific solution, once that solution has been loaded properly, e.g. by trying to start VS several times or by opening VS first without the solution and then loading the solution after VS has been started.
Therefore my current guess is that this has to do with a caching mechanism or temporary files of some sort: once the VA/VS initialization gets beyond a certain point there are no problems anymore and the solution loads successfully.
In the meantime I believe I've successfully opened all my solutions so I don't expect the issue to reappear; it's very hard to reproduce for me now... |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Jul 31 2018 : 4:07:58 PM
|
So far as I can tell, the problems the two of you are seeing are unrelated -- or if they are, they have completely different symptoms.
Can you check to see if VS reports any errors in the activity log? The log is an xml file located in your Roaming directory:
C:\Users\<username>\AppData\Roaming\Microsoft\VisualStudio\15.0_<random number>\ActivityLog.xml
If the problem is indeed related to VA parsing/initialization, you might be able to repro by pressing the Rebuild button on the Performance page of the VA Options dlg and then restarting VS.
|
|
|
|
NafetsPB
Junior Member
Germany
22 Posts |
Posted - Aug 01 2018 : 03:04:10 AM
|
quote:
Originally posted by sean
If the problem is indeed related to VA parsing/initialization, you might be able to repro by pressing the Rebuild button on the Performance page of the VA Options dlg and then restarting VS.
Yes indeed. I was able to reproduce it by using the Rebuild button: Every time I hit that button and restart VS, it quits itself again shortly after opening the solution.
However, after another restart my Visual Studio reports "A previous session terminated unexpectedly. Disabling extention 'Google Test Adapter 0.13.3.1151' might help prevent similar issues." (which it did NOT report previously, without forcing the rebuild in VA).
So I disabled the Google Test Adapter extention and tried another rebuild and that worked without problems every time. Therefore it seems to me that at least the issues that I'm seeing right now might be caused by a combination of VA 2283.1 and the Google Test Adapter extention.
Luckily the author of the Google Test Adapter extention is sitting just a few steps away in my office so I will try to investigate this together with him.
BTW, when I tried to enable logging in the VA options dialog it reported "Error creating VA_X.dll log file." so I used the registry to enable logging there. However, the va.log and vassist.log files are almost empty.
If you still need any logs (VS Activity Log, vassist.log) please let me know - and where you would like them to be sent to. Thanks!
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Aug 01 2018 : 07:04:23 AM
|
Interesting. I have just tested this here, Windows 10, VS2017 Professional, VA 2283.1 and Google Test Adapter 0.13.3.1151, and no sign of any problems loading the IDE when it is set to load a solution on startup.
So what ever is triggering this problem, it isn't quite as simple as having both extensions installed.
The error creating the log file is odd and interesting. I wonder if it is a useful clue, or just a red herring. From this page:
https://docs.wholetomato.com/default.asp?W305
the log file's should be being written to:
If you have write access to C:C:\va.log
C:\vassist.log
If you do not have write access to C:%TEMP%\va.log
%TEMP%\vassist.log
C:\Users\%USERNAME%\AppData\Local\Microsoft\VisualStudio\<IDE version>\Extensions\<random hash>\Data\Startup.log
C:\Users\%USERNAME%\AppData\Local\Microsoft\VisualStudio\<IDE version>\Extensions\<random hash>\Data\<IDE version>_1\errors.log
Could you just check to see that the account you are loading the IDE with has write access to these locations? VA does store data under the Extensions install directory, so not having write access there sometimes could cause some problems. I would hope it did not cause a crash, but it would certainly be an odd situation for the IDE.
Another thought, could you please export your VA and IDE settings and send them to me:
VA Options -> Performance -> Export Settings
IDE tools menu -> Import and Export Settings -> Export selected environment settings
I can then import them here and see if I can reproduce the problem with Google Test Adapter installed. I doubt it will be this easy, sad to say, but its a simple test so worth a try. |
zen is the art of being at one with the two'ness |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Aug 01 2018 : 09:27:51 AM
|
I have the settings and log files, thank you for these. Unfortunately the settings don't make any difference, still no sign of the problem here. Not much of a surprise, but it was worth testing anyway.
Do you know if the log files existed before starting this latest test run? The reason I ask is that the Startup.log contains a block of lines reporting that one of the VA symbol database files is corrupt. The log file continues past this, so it probably isn't causing an instant crash, but it caught my eye. So I am wondering if this is from a previous run, since you have been doing a VA symbol database rebuild.
A related thought, if you make a new, default C++ MFC application and have this open on startup, can you still reproduce the crash? I am wondering if it is any solution that causes the problem, or only "real", and thus large solutions that trigger this crash. Searching for useful clues here. |
zen is the art of being at one with the two'ness |
|
|
|
NafetsPB
Junior Member
Germany
22 Posts |
Posted - Aug 01 2018 : 09:36:40 AM
|
quote:
Originally posted by feline
Could you just check to see that the account you are loading the IDE with has write access to these locations? VA does store data under the Extensions install directory, so not having write access there sometimes could cause some problems. I would hope it did not cause a crash, but it would certainly be an odd situation for the IDE.
I have administrative permissions on my machine therefore also write access to C: but VA nevertheless creates its logs in %TEMP%, not in C: directly, after changing the registry key. If I try to use the UI (Performance page -> Enable logging) the error message appears and the checkbox is disabled afterwards. When I reenter the options dialog the logging checkbox is enabled and checked, though.
quote:
Originally posted by feline
Another thought, could you please export your VA and IDE settings and send them to me:
I did just that by using your "Contact Us" form as you described above in this thread. The ZIP file also includes the Startup, error, and VA logs I currently have.
The only interesting entries in the Startup.log of Visual Studio read something like this:
GetSymDefStrs idx [...]Data\vs15_1\net\Db89Ds.db is corrupt
Does this ring a bell? |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Aug 01 2018 : 10:11:40 AM
|
The logging check box in the VA Options dialog does behave somewhat like this, just without the error message, and it should become ticked and disabled. When I turn on VA logging in the dialog I get a message box telling me where the log file is going to be saved, which is my %TEMP% directory, even though, like you, I am logged in with an admin account.
But not being able to write the log file when the IDE is open and you turn on VA logging, but the file is written when you use the registry key, that is strange. Can you double check that there is no existing "va.log" file in your %TEMP% directory and try turning on VA logging again in the options dialog? I would just like to get rid of one strange problem if possible.
The corrupt file message does not mean much to me. This is one of VA's symbol database files, so I am wondering if you had the IDE doing a symbol database rebuild when this log file was generated, or if VA was opening an existing symbol database. I would not expect to get a message like this during a symbol database rebuild, and the log files do go on past this message, so it didn't happen the instant before a crash. |
zen is the art of being at one with the two'ness |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Aug 01 2018 : 11:58:55 AM
|
Can you check to see if VS reports any errors in the activity log? The log is an xml file located in your Roaming directory:
C:\Users\<username>\AppData\Roaming\Microsoft\VisualStudio\15.0_<random number>\ActivityLog.xml
|
|
|
|
ChrisG
Whole Tomato Software
USA
299 Posts |
Posted - Aug 02 2018 : 01:13:28 AM
|
Are you able to reproduce the issue using the googletest\msvc\gtest.sln solution from the google test release zip?
https://github.com/google/googletest/releases/tag/release-1.8.0
It's an old solution, so you will be prompted to perform a one-way upgrade. Simply select OK and you can build the solution in debug to see the tests in the Test Explorer. |
|
|
|
NafetsPB
Junior Member
Germany
22 Posts |
Posted - Aug 02 2018 : 02:33:19 AM
|
quote:
Originally posted by feline
But not being able to write the log file when the IDE is open and you turn on VA logging, but the file is written when you use the registry key, that is strange. Can you double check that there is no existing "va.log" file in your %TEMP% directory and try turning on VA logging again in the options dialog? I would just like to get rid of one strange problem if possible.
I was able to reproduce and "fix" that logging error message problem this morning. The first thing I did this morning was trying to set the "enable logging" checkbox again without fiddling with the registry and that worked (a dialog appeared that told me where the log file will be, no error message). After a few tests I came up with the following sequence to reproduce the logging error message ("Error creating VA_X.dll log file.") that I was seeing previously:
0. Make sure that no instance of VS is running (kill all "devenv.exe" processes)
1. Use regedit to set HKEY_CURRENT_USER\Software\Whole Tomato\Logging to "1"
2. Start Visual Studio 2017 (with or without a solution, no difference)
That instance of VS never starts up properly, though. There is a splash screen
in the background but the main window of VS never shows up. You can see this in
the task manager, though: There is a "devenv.exe" instance running, no window.
3. Start Visual Studio again (!) while the other instance is still there.
That instance starts up properly and shows the main window of VS.
4. Use the "Enable Logging" checkbox in the VA options of that instance.
The error message "Error creating VA_X.dll log file." appears.
To get rid of the error message there are two options:
a. Kill all "devenv.exe" processes using the task manager.
b. Avoid setting the registry key "Logging" to "1"; only use the VA dialog.
It seems that my problem was that the "Logging" registry key was changed before I tried using the checkbox in the VA options which triggers a hanging instance of devenv.exe which in turn causes the error message in all additional instances of VS as long as the first one still hangs.
That would also explain the error message ("Error creating VA_X.dll log file.") because the hanging instance of VS is somehow using that DLL in the background.
Regarding the crashing/stopping issues I will try to get back to you with more information as soon as I can and time allows. |
|
|
|
NafetsPB
Junior Member
Germany
22 Posts |
Posted - Aug 02 2018 : 05:29:03 AM
|
quote:
Originally posted by sean
Can you check to see if VS reports any errors in the activity log? The log is an xml file located in your Roaming directory:
C:\Users\<username>\AppData\Roaming\Microsoft\VisualStudio\15.0_<random number>\ActivityLog.xml
Well, the only entries of type "error" that I see in the ActivityLog.xml are the following:
<entry>
<record>736</record>
<time>2018/08/02 09:10:02.081</time>
<type>Error</type>
<source>Extension Manager</source>
<description>Extension will not be loaded because an extension with the same ID
'Microsoft.Windows.DevelopmentKit.Desktop' is already loaded at
C:\PROGRAM FILES (X86)\COMMON FILES\MICROSOFT\EXTENSIONMANAGEREXTENSIONS\MICROSOFT\WINDOWS KITS\10\DESKTOP SDK\...
</description>
<path>C:\PROGRAM FILES (X86)\COMMON FILES\MICROSOFT\EXTENSIONMANAGEREXTENSIONS\MICROSOFT\WINDOWS KITS\8.1\DESKTOP SDK\</path>
</entry>
<entry>
<record>737</record>
<time>2018/08/02 09:10:02.081</time>
<type>Error</type>
<source>Extension Manager</source>
<description>Extension will not be loaded because an extension with the same ID
'Microsoft.Windows.DevelopmentKit.WindowsStore' is already loaded at
C:\PROGRAM FILES (X86)\COMMON FILES\MICROSOFT\EXTENSIONMANAGEREXTENSIONS\MICROSOFT\WINDOWS KITS\10\WINDOWS STORE SDK\...
</description>
<path>C:\PROGRAM FILES (X86)\COMMON FILES\MICROSOFT\EXTENSIONMANAGEREXTENSIONS\MICROSOFT\WINDOWS KITS\8.1\WINDOWS STORE SDK\</path>
</entry>
I don't think they are related to the issue that I'm seeing. Furthermore, they are always in the ActivityLog.xml, no matter whether the start of Visual Studio completes successfully or not.
[Edited by sean to reduce horizontal scroll] |
Edited by - sean on Aug 06 2018 1:08:49 PM |
|
|
|
NafetsPB
Junior Member
Germany
22 Posts |
Posted - Aug 02 2018 : 05:36:23 AM
|
quote:
Originally posted by feline
A related thought, if you make a new, default C++ MFC application and have this open on startup, can you still reproduce the crash? I am wondering if it is any solution that causes the problem, or only "real", and thus large solutions that trigger this crash. Searching for useful clues here.
I just tried that. With a default C++ MFC application there are no problems. I restarted Visual Studio several times and asked VA to rebuild every time. No issues. With a "real" aka large solution I can trigger the "crash" (which I rather see as a forced shutdown of some sort because there are no traces of a real crash anywhere in any log). |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Aug 02 2018 : 12:15:26 PM
|
quote:
Originally posted by NafetsPB
Well, the only entries of type "error" that I see in the ActivityLog.xml are the following:
I don't think they are related to the issue that I'm seeing. Furthermore, they are always in the ActivityLog.xml, no matter whether the start of Visual Studio completes successfully or not.
Thanks for checking. I just wanted to know if the log showed anything related to the message you get re: Google Test Adapter. Sometimes the activityLog will record a callstack for exceptions that VS reports about. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Aug 02 2018 : 1:33:42 PM
|
Would you be able to send me the .SLN and all of the project files for the solution that has this problem?
There won't be any code, so it may be acceptable to send these files in for testing purposes. The IDE will load an empty solution like this, and I can always make dummy code files for the file references, if required.
Since this problem is solution specific, and so very fast, it is almost as if the problem is happening while loading the solution / project files, before code file parsing starts. |
zen is the art of being at one with the two'ness |
|
|
|
NafetsPB
Junior Member
Germany
22 Posts |
Posted - Aug 03 2018 : 02:31:01 AM
|
quote:
Originally posted by sean
Thanks for checking. I just wanted to know if the log showed anything related to the message you get re: Google Test Adapter. Sometimes the activityLog will record a callstack for exceptions that VS reports about.
I don't think that the Google Test Adapter is causing these issues. In my recent tests it didn't matter whether the Google Test Adapter extension was enabled or disabled, even though Visual Studio "blames" that extension to be the reason for its restarts/crashes. A difference (aka no startup problems) is only noticeable whenever I disable Visual Assist. Even though I somehow have the feeling that this is more a problem of Visual Studio itself - or even a particular solution - than of Visual Assist (see my following post). |
|
|
|
NafetsPB
Junior Member
Germany
22 Posts |
Posted - Aug 03 2018 : 02:54:19 AM
|
quote:
Originally posted by feline
Would you be able to send me the .SLN and all of the project files for the solution that has this problem?
Well, even though there might not be any code involved I'm not in a position to decide if I can send you the .SLN and all of the project files. I actually doubt that this would be possible since it is my company's commercial product solution... If it would be my own personal project I would be more than happy to send it to you.
quote:
Originally posted by feline
Since this problem is solution specific, and so very fast, it is almost as if the problem is happening while loading the solution / project files, before code file parsing starts.
I agree that this problem is solution specific, and it is also Visual Studio specific:
This morning I upgraded to the lastest version of VS (15.7.6) and it made the situation much worse for a while - which is quite interesting: After upgrading Visual Studio from 15.7.5 to 15.7.6 I was not able to start Visual Studio with a particular solution as long as Visual Assist (2283.1) was enabled, only disabling the extension helped. With another (very similar) solution there was no such problem.
This crash/shutdown happened at least 10 times. However, after some debugging and more tries with that solution it now opens up fine (again) with Visual Assist enabled.
So this behavior is very hard to reproduce; and somehow I believe that this is an issue related to Visual Studio itself and not Visual Assist. In the Release Notes of VS Microsoft claims to have fixed the following issues:
quote:
- In 15.7 users may see extensions load without all of their assets and cause VS to crash. This has been addressed for 15.7.6.
- Visual Studio 2017 version 15.7.5 crashes when opening a solution.
Based on these statements I had some hope that this might also solve the issues that I'm seeing. However, after installing that version the situation got worse for me. Very strange!
Right now the solution opens again without problems (whatever the reason might be) so I will resume my daily work now. If I find any additional clues, logs, etc. I will let you know. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Aug 03 2018 : 09:43:58 AM
|
An IDE problem is certainly possible, and it would not be the first time I have seen something in the IDE cause a crash, but never with this particular combination of triggers.
If the problem does start up again, you might want to try making a new default IDE profile. To do this, run the command:
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\devenv.exe" /RootSuffix VATest
You will need to use the correct path to devenv.exe, so it will probably be:
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\devenv.exe" /RootSuffix VATest
when you run this you will be asked which set of default IDE settings you want to use. Also none of your extensions will be installed, but you can simply install any missing extensions from the online extension store. If there is no sign of the problem with this profile then this will suggest that something is corrupt inside your main IDE profile, and is a factor in the crash. If you still get the crash then we can probably rule out a profile problem.
To return to your default profile just load the IDE normally, without any command line switches.
Hopefully everything starts working normally again for you, and you can get back to working and not trying to debug this nasty problem. |
zen is the art of being at one with the two'ness |
|
|
|
NafetsPB
Junior Member
Germany
22 Posts |
Posted - Aug 06 2018 : 02:08:49 AM
|
quote:
Originally posted by feline
If the problem does start up again, you might want to try making a new default IDE profile.
I tried to do that but when I install Visual Assist while using the new default IDE profile it only installs version 2270.0 from the online extension store, not 2283.1 or 2283.2, so of course the IDE starts up fine. That test is rather invalid, however, because my regular IDE profile also seems to work fine using version 2270 of VA... I also tried to force 2283.2 to install to that new default IDE profile but could not find the proper way to do it (it kept installing to my regular profile). |
|
|
|
NafetsPB
Junior Member
Germany
22 Posts |
Posted - Aug 06 2018 : 03:02:12 AM
|
Well, I have to quote myself here...
quote:
Originally posted by NafetsPB
That test is rather invalid, however, because my regular IDE profile also seems to work fine using version 2270 of VA...
After I posted that comment I decided to try 2270.0 again in my regular IDE profile because that version didn't cause any problems in the past and the problems only started appearing with the installation of 2283.1.
Well, what can I say, after installing 2270.0 again VS started to show the exact same behavior as before with 2283.1 and 2283.2 :(. I was not able to open one of my (large) solutions anymore, even with 2270.0.
So I decided to rename the .vs directory within that solution folder (to __.vs__) so that the IDE would create a new one on startup. That trick helped me in the past to get rid of other nasty problems so why not give it a try.
And as soon as I did that the IDE started up properly, no matter which version of Visual Assist I was using.
I am now trying to analyze this more systematically but my current feeling is that this is rather a problem of the IDE (as already assumed) and the solution (which holds the .vs directory as well) and not of Visual Assist.
I also updated to 2283.2 this morning to give that version a spin... |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Aug 06 2018 : 1:14:41 PM
|
| Interesting. Thanks for the update. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Aug 06 2018 : 1:17:27 PM
|
| I have seen a few strange problems where changing or resetting the IDE profile fixes the problem, even when using the same solution and settings. So this looks to be similar. Hopefully this has fixed the problem for you, and it stays fixed. |
zen is the art of being at one with the two'ness |
|
|
|
NafetsPB
Junior Member
Germany
22 Posts |
Posted - Aug 07 2018 : 01:55:26 AM
|
After an entire day of opening and closing all previously affected solutions I'm quite optimistic that the deletion of the .vs directory within the solution did the trick, at least for me.
In the meantime I asked my coworkers to upgrade their Visual Assist extensions as well so we can test the behavior on more than just my machine. If there is anything odd happening I will let you know.
feline, sean, accord, and ChrisG of Whole Tomato Software, thank you very much for your fast, very helpful, and professional support in this forum! |
|
|
| |
Topic |
|
VS 2017 crashing after 2283.1 install
