| T O P I C R E V I E W |
| jeevcat |
Posted - May 08 2017 : 09:06:54 AM
I am consistently receiving an error whenever I work on my UE4 project after around 10 minutes or so, usually after trying a "Toggle Code/Header command."
While Visual Studio doesn't crash, I have to restart Visual studio to get any VA functionality working again.
In the ActivityLog.xml file, I get the same error every time:
System.InvalidOperationException: BuildWindowCore failed to return the hosted child window handle.
at System.Windows.Interop.HwndHost.BuildWindow(HandleRef hwndParent)
at System.Windows.Interop.HwndHost.BuildOrReparentWindow()
at System.Windows.Interop.HwndHost.OnSourceChanged(Object sender, SourceChangedEventArgs e)
at System.Windows.SourceChangedEventArgs.InvokeEventHandler(Delegate genericHandler, Object genericTarget)
at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs)
at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
at System.Windows.UIElement.RaiseEvent(RoutedEventArgs e)
at System.Windows.PresentationSource.UpdateSourceOfElement(DependencyObject doTarget, DependencyObject doAncestor, DependencyObject doOldParent)
at System.Windows.PresentationSource.OnVisualAncestorChanged(DependencyObject uie, AncestorChangedEventArgs e)
at System.Windows.UIElement.OnVisualAncestorChanged(Object sender, AncestorChangedEventArgs e)
at System.Windows.Media.Visual.ProcessAncestorChangedNotificationRecursive(DependencyObject e, AncestorChangedEventArgs args)
at System.Windows.Media.Visual.FireOnVisualParentChanged(DependencyObject oldParent)
at System.Windows.Media.Visual.AddVisualChild(Visual child)
at System.Windows.Media.VisualCollection.ConnectChild(Int32 index, Visual value)
at System.Windows.Media.VisualCollection.Insert(Int32 index, Visual visual)
at System.Windows.Controls.UIElementCollection.InsertInternal(Int32 index, UIElement element)
at System.Windows.Controls.UIElementCollection.Insert(Int32 index, UIElement element)
at WholeTomatoSoftware.VisualAssist.NavBar.VaCodeWindowMargin.a(IWpfTextViewHost A_0, Boolean A_1)
at u.a(Object A_0, EventArgs A_1)
at Microsoft.VisualStudio.Text.Utilities.GuardedOperations.RaiseEvent(Object sender, EventHandler eventHandlers) |
| 30 L A T E S T R E P L I E S (Newest First) |
| sean |
Posted - Jul 05 2017 : 11:00:52 AM
I believe that both VA and VS are independently working on reducing memory usage.
An interim alternative to consider (it might be more or less disruptive to your workflow) is to work in two instances of Visual Studio. Use one for editing and another for debugging so that out of memory crashes caused by debugging don't bring down the editing instance. |
| jeevcat |
Posted - Jul 05 2017 : 04:04:09 AM
I've had that setting enabled for a long time, but it still always loaded the UE4 modules, which I assume are taking up most of the memory.
For now I've added a rule to specifically exclude *UE4*. This is not ideal, as it means I can't easily debug the Engine source. However, it's not too much more effort to load the correct modules manually when needed.
When I debug now, VS loads the symbols for 2 modules, instead of the ~300 VS was loading before. It hasn't crashed for me since I've made this change.
So it seems for now that my problem is solved, although my workflow is not *ideal*. Is there any likelihood that I'd be able to utilize all my available RAM and just load all the symbols I wanted? Or would I be waiting on significant changes made by Visual Studio (years?). |
| sean |
Posted - Jul 01 2017 : 4:46:34 PM
Debug symbols can use a lot of memory. If you haven't checked "Debug | Options | Symbols | Only specified modules" you will get an alert from VS2017 telling you that getting symbols takes time but those symbols also use up memory.
If you do check "Only specified modules", then when you want to explicitly load symbols for a module, you can right-click in the Modules or Call Stack toolwindows and select Load Symbols (if you haven't added the module to the list in the debugger settings).
|
| jeevcat |
Posted - Jul 01 2017 : 4:27:09 PM
Everything is working much better now. I've upgraded back to VS 2017 and I'm using build 2223 of Visual Assist.
The only time I seem to have problems is during and after debugging. If I always `Start without Debugging`, I never seem to have any issues anymore. Could be that debugging uses too much memory? Do you know of any ways which I can do a more "barebones" debug that might use less RAM? |
| jeevcat |
Posted - Jun 22 2017 : 7:29:20 PM
Anywhere from 0 to 10 or so. I'll try to keep my number of tabs as low as possible. |
| sean |
Posted - Jun 21 2017 : 3:53:19 PM
When your solution loads, how many editor tabs are automatically loaded? |
| jeevcat |
Posted - Jun 21 2017 : 08:54:11 AM
Since renaming CodeInspection, I'm still getting the same `BuildWindowCore failed to return the hosted child window handle` exception.
I'm not 100% sure if I had activated the tab previously. I'll try to be aware next time it happens.
The process of the exception occurring today was:
- I noticed that Alt-Shift-Q wouldn't work. My PC would make a chime sound instead. At this point I feel like VA has already internally crashed?
- I checked the 'Quick actions and refactoring' menu. It was empty except for `Edit Refactoring Snippets'.
- I went to the Visual Assist Options dialog. It opened however the UI was all mangled, with large parts of the dialog blank.
- I right-clicked and selected 'Toggle Header / Code File'. Visual Studio crash to the above exception. |
| sean |
Posted - Jun 20 2017 : 5:32:25 PM
Is the error occurring for tabs that had already been opened, or for tabs that were created when the solution was opened but that hadn't been activated yet? |
| jeevcat |
Posted - Jun 20 2017 : 5:29:43 PM
Thanks for the response. The error is occurring at different times for me know, so I thought it might be a different problem.
I've renamed the CodeInspection pkgdef and I'll see how things go. |
| sean |
Posted - Jun 20 2017 : 4:54:10 PM
That was another 'BuildWindowCore failed to return the hosted child window handle' exception. If you have Code Inspection disabled, you could try deleting (or renaming) the VaCodeInspections.pkgdef to prevent VS from loading the dlls that provide Code Inspection functionality to save more memory. |
| jeevcat |
Posted - Jun 20 2017 : 2:02:43 PM
I've just submitted another dumpfile via the contact form. I'm now using 2219. Everything seems a lot more stable on this build.
But this crash seems to happen pretty consistently on this build, after switching to another file on another tab. Unfortunately doesn't seem to have broken on a VA process. I created a dump with the heap, for this reason. |
| sean |
Posted - Jun 08 2017 : 4:34:06 PM
The number of files in your solution is moderate but the number of projects is on the higher side of things. Pay attention to how much memory is being used by VS when things start to randomly fail. You are also welcome to submit crash dumps via https://www.wholetomato.com/support/contact.asp -- in case there is something about one of the random crashes we are able to actually address. |
| jeffno |
Posted - Jun 08 2017 : 3:33:03 PM
quote:
Originally posted by jeevcat
Ahh good to hear I'm not the only one. Are you also using UE4? Or a very large project/solution?
I also used to be able to use VA with no issues. I thought it might have something to do with updating to newer versions of VS or Windows. But I didn't consider rolling back to older versions of VA.
No UE4. The solution is 113 projects containing 893 .cpp files an 1217 .cs files. Not sure if that counts as "big".
Unfortunately, same issues with VA 2118. I'll go back a bit farther...
|
| jeevcat |
Posted - Jun 08 2017 : 1:15:44 PM
Ahh good to hear I'm not the only one. Are you also using UE4? Or a very large project/solution?
I also used to be able to use VA with no issues. I thought it might have something to do with updating to newer versions of VS or Windows. But I didn't consider rolling back to older versions of VA. |
| jeffno |
Posted - Jun 08 2017 : 1:11:41 PM
FYI, I'm seeing the same symptoms and stack trace on the latest build of VA in VS2015. I tried reducing memory consumption using the tricks posted by sean, but I'm still getting many random freezes and crashes in VS. This began happening immediately after upgrade from a roughly year-old build of VA (I don't recall which) to the most recent, and I don't think there are any other changes to my VS setup that could explain these issues. I'm going to binary search through recent builds to see if I can find one that doesn't elicit the problems... |
| jeevcat |
Posted - Jun 07 2017 : 01:14:37 AM
Wow. That seems like a pretty huge oversight my Microsoft. Probably a lot of work to move to 64-bit.
I'll try some of the suggestions on the page that you linked. Thanks for the continued support! |
| sean |
Posted - Jun 07 2017 : 01:06:47 AM
Visual Studio is a 32-bit process, so the 32GB is lost on a single instance of it. To be sure, 32GB is helpful if you are running multiple instances, but each instance only sees 4GB of the total. Even then, since there are multiple heaps in the process (managed and native at that), memory exhaustion can occur well before the process is using even 3GB. |
| jeevcat |
Posted - Jun 07 2017 : 12:26:59 AM
It does make sense that it could be caused by memory exhaustion, as I only get this issue when using UE4 projects, which are always huge. Also actually launching the UE4 project and game uses crazy amounts of RAM too.
However, I have 32 GB of RAM and and Windows has allocated about 10 GB of virtual memory. I'm increasing the virtual memory to ~100 GB now to see if this has any affect. |
| sean |
Posted - Jun 06 2017 : 3:18:05 PM
Thanks for sending the dump. Most of these crash dumps have been related to window creation failures and this one is similar. Some of the window creation failures are in VA code and we can definitely add more error checks, but we can't add failure checks to Visual Studio code that assumes windows will always be created successfully. I still think the random nature of the crashes point to memory exhaustion and since this full heap dump is nearly 2GB, that lends more credence to that line of thought. We'll get the latest one addressed and get a new build out to you.
Here are some suggestions for dealing with memory exhaustion in Visual Studio:
https://docs.wholetomato.com/default.asp?W730 |
| jeevcat |
Posted - Jun 06 2017 : 02:09:15 AM
I'm just uploading a dumpfile with heap now.
This crash actually happened in a VA DLL. VA stopped working at some point, so I tried to cause a crash -- and managed to get one when I went to the VA settings menu. |
| sean |
Posted - Jun 05 2017 : 4:40:21 PM
We received the dump and it is basically the same as the one I commented on in the thread post dated May 25 at 2:07:48 PM.
Next time, please capture a full heap dump. The dump will likely be over a GB. Zip the file, upload the zip using the contact form and put "case 107979" in the subject. |
| jeevcat |
Posted - Jun 05 2017 : 2:02:31 PM
I have just uploaded the dump to the form, as requested. |
| sean |
Posted - Jun 05 2017 : 1:50:12 PM
Yes, please try using the contact form https://www.wholetomato.com/support/contact.asp . It supports large attachments. Reference the case number in the subject field |
| jeevcat |
Posted - Jun 05 2017 : 1:41:47 PM
I sent an email. Should I try the contact form instead? |
| sean |
Posted - Jun 05 2017 : 12:57:42 PM
I don't see any new files or messages in the case. Did you use the contact form or send email? |
| jeevcat |
Posted - Jun 05 2017 : 06:07:24 AM
I've forwarded another dump file.
Unfortunately, it looks like I'm only able to catch crashes after VA has stopped working. The call stack doesn't have any VA DLLs in it.
Also it was very obvious that VA had stopped working before this crash. Even the code color highlighting was not working correctly.
|
| jeevcat |
Posted - May 31 2017 : 12:59:30 PM
I just noticed the new build in my inbox. Thanks for that. I'll keep testing and see if I can catch any more crashes. |
| sean |
Posted - May 30 2017 : 5:53:51 PM
>Yes it was a hard crash - I was unable to continue.
Thanks for the details.
>Should I still be trying to get minidumps to submit?
I will forward another update, but yes, if you experience a crash, submit a minidump. |
| jeevcat |
Posted - May 30 2017 : 04:28:51 AM
Sorry for the delayed reply. In response to your questions:
Yes it was a hard crash - I was unable to continue.
I couldn't tell you with certainty which settings page was displayed by default, but it may very likely have been the Code Inspection settings menu as I had just disabled code inspection previously.
It was definitely the first time I had opened the settings menu, as I had very recently loaded the solution in a fresh instance of VS.
Just to clarify the issue: I almost always notice peculiarities/broken VA features before a hard crash occurs. It seems as if a "soft crash" is occuring within VA which eventually causes VS to die.
Should I still be trying to get minidumps to submit? Thanks for the continued support. |
| sean |
Posted - May 26 2017 : 1:41:08 PM
Glad to hear of some improvement. I suspect memory exhaustion due to Code Inspection was causing random problems. We are continuing to work on that.
Regarding the settings window, after you captured the dump, did you try to let it continue or was it a hard crash?
Do you know what settings page was being displayed by default?
Do you recall if it was the first time you had opened the dialog in that instance of Visual Studio? |
