Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Technical Support
 VS Crash with VA_X and VisualGDB

You must be registered to post a reply.
Click here to register.

Screensize:
UserName:
Password:
Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji
   
Message:

Forum code is on.
Html is off.

 
Check to subscribe to this topic.
   

T O P I C    R E V I E W
wilstark 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).
3   L A T E S T    R E P L I E S    (Newest First)
feline 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.
wilstark 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 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.

© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000