| Author |
 Topic  |
|
|
wilstark
Junior Member
USA
22 Posts |
 Posted - Mar 11 2019 : 6:28:32 PM
|
VS2017 15.8.6
VAssistX 10.9.2270.0
VisualGDB 5.4R2 build 2753.
The following sequence is fine if VA_X is disabled. But if VA_X is enabled, you get the crash at the end, and the callstack originates in VA_X.
---
Open Visual Studio:
File -> New -> Project -> � -> Visual C# -> Windows Desktop -> Windows Forms App.
� finish the wizard� choose project properties. See the properties. No crash. All good.
Right-click the solution -> Add -> New Project -> VisualGDB -> Linux Project Wizard
Application
CMake
GNU Make
Advanced CMake Project Subsystem checked.
�Next�
Build project over network (uses my configured Linux box, all good here)
�Next�
Store files on the remote machine (default, recommended)
�Finish�
Right-click the C# project, choose properties (as before). Crash VS.
(If C# project's properties were already open, then close and re-open to crash.)
---
call stack:
> user32.dll!__InternalCallWinProc@20 () Unknown
user32.dll!UserCallWinProcCheckWow() Unknown
user32.dll!DispatchMessageWorker() Unknown
user32.dll!_DispatchMessageW@4 () Unknown
VA_X.dll!146ffe3d() Unknown
[Frames below may be incorrect and/or missing, no symbols loaded for VA_X.dll] Unknown
[External Code]
*** UPDATE ***
I have reproduced this issue with VA_X disabled. I'm reporting it to VisualGDB (Sysprogs). |
Edited by - wilstark on Mar 11 2019 6:37:41 PM |
|
|
feline
Whole Tomato Software
United Kingdom
18746 Posts |
Posted - Mar 12 2019 : 08:14:51 AM
|
When you say with VA disabled, do you mean disabled via the menu item:
VAssistX -> Enable/Disable Visual Assist X
or by going into the dialog:
IDE tools menu -> Extensions and Updates...
and disabling VA, which requires an IDE restart? If you have just used the menu item then VA is still loaded, but trying to keep out of the way. If you have used the extensions dialog and restarted, then VA is effectively uninstalled, so should have zero effect here.
From the steps, it sounds unlikely that VA has much to do with this, but I certainly don't want to rule us out just based on that theory. |
zen is the art of being at one with the two'ness |
 |
|
|
wilstark
Junior Member
USA
22 Posts |
Posted - Mar 12 2019 : 4:28:47 PM
|
| I am able to reproduce this without Visual Assist X installed, and am working with VisualGDB support. Looks like VA_X is (possibly) wrongly implicated by a random memory write. Sorry for the trouble. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18746 Posts |
Posted - Mar 13 2019 : 05:39:09 AM
|
| Thank you for the update, and really not a problem. I would much rather check this in case VA is a factor, rather than ignore VA being in the call stack. Hopefully VisualGDB can get to the bottom of this fairly quickly for you. |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
VS Crash with VA_X and VisualGDB
