dotmemory snapshot crashing application - prism

Resharper Ultimate: 2016.3.2
DotMemory: 2016.3.2
Visual studio 2017
Windows 7
Prism 6.3.0
Ninject
This is a bit of a strange one, so I'm not sure exactly how to describe it, but i'll give it a shot.
Originally, I had pages set up to register with their regions, so all my pages were declared as follows
_kernel.Bind<IPageView, PageView>().To<PageView>();
followed by binding them to the region.
_regionManager.RegisterViewWithRegion(RegionNames.ContentRegion, typeof(PageView));
While updating things, I decided rather than having the hassle of binding the pages, and registering them with the region, I'd switch to using RequestNavigate, so I removed registering the view with the region, and changed the binding to
_kernel.RegisterTypeForNavigation<PageView>( PageNames.MyPage);
In debug mode this all worked perfectly fine. However this is where things get odd. I ran dotmemory to do some leak testing and found that if I took a snapshot before entering certain pages, the software would crash. If i didn't take a snapshot, or I took a snapshot after entering the page, nothing crashes.
Additionally, if I add
_kernel.get<PageView>();
after binding the page, I also have no issues. (so right now this is my terrible temp fix)
I'm just wondering if anyone has any idea why this might be happening. The only two conclusions I've come up with are either
a) RequestNavigate isn't resolving through ninject correctly.
b) Somehow getting the snapshot from dotmemory is clearing anything that hasn't already been resolved from the kernel.
I'm not expecting much, but if anyone has any ideas what may be causing this it'd help a fair bit.

Related

Xamarin Forms Universal Windows Platform app blocked by AppLocker

There is a question here about this already (though,short of re-installing Windows, which I'm obviously trying to avoid, the other solutions don't work for me), but I have some research to add, and a possible solution... which I don't understand, but perhaps someone here is able to shed light on how to implement it? I'm using Visual Studio 2015 Community on Windows 10 Pro x-64 with Anniversary Update (and latest cumulative update).
There is a possible work-around - details at https://social.technet.microsoft.com/Forums/windows/en-US/2f51398c-cef2-4686-9505-904d3f71ef6d/windows-10-applocker-packaged-app-white-list-blocks-store?forum=win10itprogeneral - where the resolution is to allow all Windows App Store apps, however no steps are given, so I don't know how to do that.
There is a relevant hot fix at https://support.microsoft.com/en-gb/kb/2719305, however that is targetting an older version of Windows, so I'm not sure of the repercussions of trying that. I'm leaving that as my last resort short of re-installing.
And finally, there is re-installing, as per the other thread on here, as the Anniversary Update is considered the suspect (and I'm past the rollback window). I already had the AU when I first tried UWP, so I never had it working to begin with to know if this is the culprit or not. I have never touched applocker myself (had never heard of it) - I have this problem out of the box.
Apart from the time involved, I don't want to re-install as there has been mixed success with it - for one person it fixed it, for another it fixed it initially but the problem came back. I am trying to get a permanent fix (and only re-install if I can't find one).
Anyone know a permanent fix for this? Or how to implement the first suggestion? Or implications of the second?
P.S. for the sake of completeness (and to pre-emptively answer this question), one of the things I already tried is the MS trouble-shooter for this issue (I think I found this one on MSDN from memory). It suggested using my MS login instead of my local user, and to change the temp environment variables back to default (I had them pointing to RAMdisk), but doing those things failed to fix the issue.
Well, I ended up re-installing Windows, having corrupted it along the way, and that ended up fixing the issue. I found along the way that the problem actually stops ALL apps from the store installing (I never did find out how to implement the store fix I mentioned in my question), and that provides a quick way to see if the problem is fixed (rather than trying to build/deploy your UWP app each time you think you've fixed it, just try installing a store app).
I did find something that MAY be a solution, at https://answers.microsoft.com/en-us/windows/forum/windows_8-winapps/this-app-wasnt-installed-error-0x80073cf9/92ec7c44-51ef-4c6a-9331-22958e01b4ec?page=1, which relates to how to recover from a corrupted user profile (I'm not being allowed to upload a snapshot of the relevant reply due to still being relatively new here. Sigh) - which I now believe to have been the cause - however I didn't get to try it out as I'd already corrupted Windows at that point. Note that none of the other solutions in that thread worked for me, so I would start with this one first, as the other solutions only worked for some people. If you have this problem then I would try that first before re-installing.
P.S. at one point it looked like the Anniversary Update may have caused the problem, however after I re-installed I tried before applying the AU, and then again with the AU, and it kept working afterwards,so that was NOT the culprit. It was the user profile/Windows being corrupt.

Visual studio 2012 doesn't rerender until resizing the main window

I am experiencing the exact same issue as this fellow, and cant seem to find any real solutions to the issue. The only solution I've been able to find so far that works it not maximizing VS. Keeping VS in windowed mode fixes the problem completely, but as soon as it returns to maximized state UI elements no longer redraw unless the stale area is put under new active focus. This makes it impossible to develop and I'm forced to return to windowed mode. I've tried disabling hardware acceleration with no luck. Any Ideas?
There are a handful of feedback reports at connect.microsoft.com that describe a similar problem. But none that ever evolved to a solution, most typically the programmer that filed the report stopped responding when asked to provide additional diagnostics.
Clearly this is an environmental problem, something is wrong with your machine. VS2012 uses WPF for rendering, it puts non-trivial demands on the machine. You do need a solid video driver and a functional DirectX stack to make it work without problems. This tends to be an issue in general, video drivers are by far the most problematic kind of driver. Problems are roughly correlated with the age of the machine and how old the operating system is.
So a good starting point is to look for a video driver update first, visit the web site of the company that made your adapter to look for the latest. Reinstall DirectX on the machine next. If you were considering a clean update of your machine before, like updating the Windows version, now would be a good time to start with a clean slate.

ASP.NET MVC3 Razor views - extremely slow editing in VS2010

I've got a relatively small project written in ASP.NET MVC3. After working a while, Visual Studio 2010 becomes very slow in Razor views (other file types work fine). With "slow" I mean "every keystroke takes around 1 second to register". It doesn't matter what that keystroke was - typing a single letter is as slow as pasting a screenful of markup. During this slowdown VS2010 consumes 1 CPU core to 100%. After I restart VS2010, everything goes smoothly again for a small while. This happens in any and all Razor views.
My PC isn't the best, but it should be enough: Core 2 Duo 6700, 4GB of RAM (currently only 75% filled with VS2010 being slow and all, so it's not a RAM shortage), Windows 7 x64.
The project is close to an end, and I remember that for most time there were no problems. This has started only recently, although I cannot imagine what could have caused it.
Does anyone have any ideas about what could be wrong and what could be done to fix it?
It is plugins - TFS/AnkvSVN and ReSharper have all caused problems for me.
Turn them off one by one, to discern which one (if only one) is causing you grief.
When you find the culprit, make sure you keep up on any patches with it.
In extreme cases, turn if off if you have a long development session and don't need it the whole time (SVN for instance could be turned on when you are ready to do commits and check ins, etc.)
The issue is resolved for me, by installing the Mvc Html5 Templates.
After the installation, I picked XHTML5 and then back HTML5 from the "Target schema" combo box. After that, the paste was instant!
Edit: I uninstalled "Mvc Html5 Templates" and the issue didn't reappear. Perhaps it has something to do with the "HTML 5 Intellisense"
Have you installed sp 1 it fixed some performance related issues when loading IntelliSense for markup
Run the Resource Monitor (CTRL+SHIFT+ESC, click Performance tab then Resource Monitor button at the bottom). Pay special attention to disk I/O and perhaps CPU usage.
Sort disk I/O by Total B/Sec descending. As you type, see if it can identify a process which is causing the issue. Hopefully it's a virus scanner or some other famous performance destroyer and not the Visual Studio process itself, which wouldn't be very helpful.
Have you tried opening the same project on a different machine? This will give you an idea whether issue is in the project or VS install. Quite obvious, but is there anything in the event viewer. Are you connected to a domain while this is happening?
Well, for me the problem has turned out to be anti virus - we use (or are made to suffer) Sunbelt Vipre on our workstations and as soon as I switch off active protection (so that's basically disabling AV completely) all of a sudden all the performance issues in all windows are gone.
Sorry for adding another answer, but there seem to be lots of different causes, so - lets list all possible fixes here.
I tried disabling ReSharper and other addons - did not work. What did work - is reapplying the SP1 again.
PS. Weird, I know. Don't ask, no idea... My guess is - VS was "repairing" itself silently at some point and restored some non-SP1 components.
PPS. You might also want to try disabling "Productivity Power Tools" addon. If you have ReSharper installed - almost all the PPT features are already there, in ReSharper.
PPPS. I have a blog post with several performance tips for Visual Studio & ReSharper, might come handy..
Have you tried Cleaning the solution?
In my case, high CPU usage started out of nowhere (WPF project). Restarts of Visual Studio didn't help, neither disabling/uninstalling addons. But Cleaning the solution did help!
I was experiencing a very similar issue on a large cshtml file in VS 2015 and was solved for me by turning off all of the automatic formatting options in Options > Text Editor > C# > Formatting > General:
I then use the "Control+K,D" key combination to format the page once I have finished making the necessary code changes.

WP7 - January tools update explodes my application. What'd I do?

I've Googled around a bit on this issue and haven't been able to come up with anyone else having an issue to this one, so a) I apologize if this is a known issue; and b) I'm thinking this proves that I must be doing something horrifically wrong, yeah? :-)
My application has a very rich landing page which is the first page that is shown after a new launch. It has a panorama control, a large background image (but much smaller than the 2000x2000 limit) and recurring and ongoing animations. Prior to updating my tools to the January refresh, this page ran relatively smoothly. After updating and running the app in the emulator, the background of this page is white (despite the fact that the emulator is on the "dark" theme), performance is quite poor (both in terms of swiping through the panorama and in terms of my recurring animations). When I run the same project on my device, all is well (since, quite obviously, my device's OS is not on the updated image).
Clearly I must be doing something grievously wrong to merit such a cataclysm, but I'm not sure what it might be. I've tried disabling bitmap caching in the places where I'm using it, removing third party tools I'm using such as Peter Torr's awesome tilt effect and his memory usage counter, and several other hail-Mary-style moves, and the problem remains. I also looked through the provided resources and change log to see if perhaps something related has changed, but I didn't see anything.
I'll try to provide example code later if it would be of any use to any would-be saviors out there, but the app is pretty complex and large in terms of lines of code and file size, so it might be a bit tricky. i just thought I'd toss this out there and see if anyone might happen to see it and think of an obvious solution.
Thanks so much in advance for your time and help.
P.S.: I cross-posted this question on the official WP7 dev forums. Sorry if that's against the rules - I'm not a regular SP-poster, as you can tell. If it's a problem, let me know and I can delete the other post.
I was ultimately able to resolve this by creating a brand new project using the updated tools and copying my code, assets, and relevant project settings into it. The app now runs flawlessly on the emulator (or, at least, the flaws in it are my flaws and not the emulator's :-)).
I believe I originally created the project on an earlier version of the SDK, so maybe I had some kind of invalid or incorrect project settings. If I get a moment later, I'll compare the project files to see if I can identify a setting or difference that explains the disparity.
Thanks to all who looked (and to Matt, who even responded :-)). I'll report back if I have any more information that might be of help.
UPDATE: Updating for anyone who might be having this issue as well - my resolution above was a false positive. Creating a new solution and copying stuff in does indeed work, but only until you save and close the new solution. Upon reopening, the problem recurs. Grrrr. I'll post back if I come up with anything else.

Arithmetic underflow or overflow exception during debugging

This is the day of weird behavior.
We have a Win32 project made with Delphi 2007, which hosts the .NET runtime and calls into .NET to show new forms, as part of a transition period.
Recently we've begun experiencing exceptions at seemingly random locations and points of our code: Arithmetic overflow or underflow.
The stack trace of one of these looks like this:
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.RunDialog(Form form)
at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
at System.Windows.Forms.Form.ShowDialog()
at Gatsoft.Gat.UI.Windows.Forms.Remanaging.RemanageForm.DelphiOpenInNewMode(String employeeCode, String departmentCode, DateTime date) in C:\Dev\VS.NET\Gatsoft\Gatsoft.Gat.UI.Windows\Forms\Remanaging\RemanageForm.Delphi.cs:line 67
In the Visual Studio solution, one of the outmost class libraries (ie. pulls in all the references it can), has set a specific debug program, targetted for the Delphi project output. This allows us to debug .NET code from Visual Studio, even though the main bulk of the program is written in Delphi.
The problem only occurs when run from the debugger, not if we just run the exe file directly (either through explorer, shortcuts, or even Ctrl+F5 inside Visual Studio).
There's apparently no spyware on the machine (as hinted by this).
Any other things we can check?
Edit: It looks like the .NET debugger is enabling this SNaN flags, and the Delphi debugger does not. We'll have to investigate this further, but for now I'll accept #Lorenzo Boccaccia's answer.
Apparently Solved
Ok, it looks like we've finally nailed this problem. The problem started occuring without having the debugger attached as well, for our testers, so we had to prioritize the problem way up.
Finally we found one common issue with the machines that had the problem, they are Dell Lattitude D620 laptops with an NVIDIA Quadro NVS 110M, with an old driver from a system image used to provision the laptops, from back in 2006.
I found one post on the web, though I lost the url when I rebooted to update the display driver, that had a .NET service crashing, mostly when the machine was busy doing something on the screen. One way to reproduce his problem was to open a command prompt to C:\ and doing a DIR /S to just force a massive amount of screen updates, which would trigger the crash.
He too had a NVIDIA video card.
The problem on my machine occured roughly every 2-4 startups of our program, but after updating the video driver I've had 123 successfull startups without any problems. (BTW I can recommend AutoHotKey for such things).
So it looks like we've found the culprit, an old/buggy NVIDIA driver.
Updated this question so that perhaps someone in the future can save some time.
Now, if you'll excuse me, I'm going to go cry in a corner.
Jinxed!
I must've jinxed it. No sooner had I posted the above update than a colleague laptop failed, after updating the video driver.
Still, I'm positive it's a problem outside of our application now, so it just remains to figure out which specific things to update.
Further updates: Ok, my machine is now apparently fixed, not so with my colleagues machine. So far we've updated the BIOS, Chipset drivers, and currently SP3 for XP is on its way in.
A burn-in test will be done tonight, where the app will be left overnight starting up, as the problem cropped up either during startup, or at the first time some WinForms .NET code was executed. This app is mainly a Delphi Win32 app, but it hosts the .NET runtime, and the problem seems to be related to .NET code. When we "boot" the .NET runtime, the problem can appear, or when we fire the first .NET window from Win32 then it can also appear.
Statistically I'm ready to release this code now. Over the night the application has been started 3051 times without errors, whereas before I updated the video driver it crashed every 2-4 times.
Prodded and found(!/?)
This bug-fixing ordeal feels like going to the doctor, where the following conversation ensues:
Doc: Does this hurt?
Me: No...
Doc: What about now?
I've prodded and poked the application and finally I think I've found something we did that introduced this problem.
In our app we host the .NET runtime, from a Delphi 2007 Win32 application, and in our glue-code we have the following line (now):
rc := CorBindToRuntimeEx('v2.0.50727', 'wks',
STARTUP_LOADER_OPTIMIZATION_MULTI_DOMAIN or STARTUP_CONCURRENT_GC,
#clsid, #iid, UnkRuntimeEngine);
The two constants in the middle there was originally just a 0, meaning pick the defaults. This change was introduced a few months ago and the problem has been slowly creeping in on us after this. The change was introduced in order to encourage ANTS profiler to load our Win32 application + hosted .NET runtime in order to do performance profiling and the changes we introduced back then made that work. Additionally, the problem with arithmetic overflow/underflow has slowly been getting worse so I bet the problem didn't appear for a while after the change so it wasn't attributed to any of the changes we did.
Also, since we only (originally) saw the problem when running through the debugger, we thought something was wrong with Visual Studio and/or Delphi.
Anyway, statistically now, with a browser on one screen doing repeated scrolling up and down triggered by a javascript (apparently needed in order to trigger the bug), then I have been able to successfully start the application 726 times with a 0 in the call, and it crashes 5 out of 17 times with the two constants there.
Doc: Does this hurt?
And let's not get into who made that change in the first place. I'm sure the culprit wants to be left anonymous... cough
a debug version of a linked dll could be compiled with signaling nan support, see http://blogs.msdn.com/oldnewthing/archive/2008/07/02/8679191.aspx for an example of this problem.
that heisenbug was caused by uninitialized variables, here there could be a linked dll enabling the snan feature of the cpu and forgetting to disable it upon returning
Do the errors occur still occur if you attach the debugger after starting the application?

Resources