I've been developing a WPF interface for the past year, and this week I've noticed I can no longer open the interface within Visual Studio 2010 without it hanging indefinitely. I'm wondering why this has just started happening. I've checked through the SQL settings for the data bindings and everything seems fine. Does anyone know of any of other options I have? I can't seem to cancel this endless loading.
I assume you have tired to reboot? For me sometimes a compile that usually takes 10 seconds will take minutes. I reboot and it works fine for a couple days or a couple hours. SP1 helped.
Finally I've found the solution. One of my datagrids was attached to a DataSet which return a list of log records. Now as the system went through testing the long grew, making the sql query take longer and longer to return. I noticed this by running the JetBrains dotTrace tool on the application, and profiled the startup sequence, this identified the SQL query which was causing the delay.
Related
Two years ago a SQL expert opened a SSMS and showed all queries as they were happening in real time. That way he saw which SQL statements were running fast and which took some time to be ran. I remember the queries to be displayed in a "CMD" look alike window. I can't remember if new queries were displayed at the top or were they shown at the bottom of the window.
For the past month I have been trying to figure out how he got this working. I looked everywhere in monitor, but I can't find anything similar to what he showed me than.
The results were similar to the "claymore eth miner window" ...
Can someone point me in the direction of getting this?
You can use sp_whoisactive to get the current running queries. It is very useful to see if currently there is blocking, locking, long running statements.
In order to get better picture of what was going on in the past, you can enable the Query Store. There are some predefined reports:
and various statistics and it is user friendly:
That is the case as of last night. Does not work for CPU or GPU "compute type"
Basically, after pressing the "Start runtime" button, it says "Preparing project runtime..." for about ten minutes and then stops. It shows the following error, "There was a problem when starting the project runtime. This should be resolved shortly. Please try again later."
I have now tried it about five times over last night and this morning.
There is no way to even access the work that is saved there. The "project" will not boot up.
Basically it is a dud at this point.
Is anyone else experiencing similar issues? What does one do?
The issues/questions and answers that I have learned since (because I was asked to clarify):
(1) The environment on Sagemaker Studio Lab is supposed to be persistent. I.e., any time one starts it, the environment, files uploaded, etc. are where it was left last. However, I was not able to start the environment any longer. Before it locked out, it would start fine. Consequently, I was not able to get to my saved work in any way shape or form. I was wondering if anyone has had this issue
Answer: Thus far not too many people are approved for Sagemaker Studio Lab. So, I may have been the first or one of the first to encounter this issue. As of this writing there does not exist a way to access ones data if one cannot spin up a virtual machine that would have access to the data using their "Start runtime" button.
(2) It is not clear where one is supposed to report issues with Sagemaker Studio Lab. On one's home page in Studio Lab, it has a link to StackOverflow under "Get answers and help others". That is how I ended up here. Though, I should have included the following hashtag (#amazon-sagemaker pointing to https://stackoverflow.com/questions/tagged/amazon-sagemaker).
Answer: I eventually found where people are submitting bug reports. And I reported the issue there (see issue 56). https://github.com/aws/studio-lab-examples/issues
(3) It was not clear to me if I was to delete my account and request a new one if I would be put on a waitlist (which supposedly is presently long). I.e., this would be the manual factory reboot option where one still loses all of ones work, but, at least has an opportunity to start again with the environment.
Answer: Once one is approved, one does not go to the waitlist. Deleting my account, requesting a new one, and setting it up to the initial state took a couple of minutes for me. And yes, I lost all my work that was on there. So, back stuff up as it was your computer in the `80s. I.e., back up externally to that environment.
I signed up for ASMSL about 2 weeks ago. As of this evening (Feb 15) I'm able to log into my runtime without any trouble at all.
Today I came across a bug that I'd like to share with everyone.
When trying to execute an SSIS package in Visual Studio (2015 and 2017 the following can happen (note this package was executed sucessfully before).
While on the bottom it clearly says the SSIS package is finished, the data flow task is still in progress (and will never finish). What also happens (don't know if consistently) a CMD window pops open with "SQLDUMPER.EXE".
This is not due to the way the steps are configured, since executing them individually might still lead to the proper results.
Note as well that in my case this problem makes Visual Studio incredibly unstable. It is not uncommon that after or during every execution Visual Studio crashes completely and is automatically shut down by Windows.
There are no error messages and I had no idea what the reason is this happened untill... (answer below)
After a lot of googling i've found a reason whya multitude of people seem to have this problem.
Right click the project and then click on properties
Click "Debugging"
Set "Run64BitRunTime" to "True"
Apparently for most people this fixes the problem.
For me however I had to come up with another solution.
Right click the project and click on properties
Click "General"
Set "TargetServerVersion" to either the target SQL server and run the package again OR set it to any SQL server version, run the package to see if it works, and if it doesn't set it to another version.
These solutions are counter intuitive because this problem seems to arrise at a random moment and the target sql server version might have been the same throughout the entire development.
I have not tried to see what happens when I deploy the bugged project to a server and see if it runs there, so any and all extra information on this problem would be appreciated.
I spent a good bit of time googling this problem. It looks like it is being reported by many people around the world. It is usually down to either x32/x64 compatibility or some miniscule issue with sorting or data sizes or compiling a custom C# script (or combination thereof).
None of these things worked for me so I rebuilt the entire package from scratch and the issue was gone.
It is far from perfect, especially if your package is large and/or complex but if nothing else works, this is your last resort.
"Run64BitRunTime" was already set to "True", but I was getting this error. so I restarted the visual studio and problem resolved.
None of the proposed solutions worked for me. I had to rebuild both the solution and the project a couple of times and this fixed it. Of course, I opened and closed the VS a couple of times in between. I guess this is a bug and you have to tinker with it to get it to work.
Stumped here. Posted a similar question before. We have a pretty large WPF app that on some machines runs great, but on others, all of a sudden, one of the CPU cores gets pinned at 100% (just one core) and the app freezes. It usually seems to happen when showing a context menu or a combobox drop-down (i.e. Popup controls) which is why we can't debug this since no user code is executing at that time. It's driving us crazy because again, on most machines it runs fine, but on a few, it freezes.
The odd thing is when we run it in a VM, it runs great there too! Crazy! Not sure what's causing this, or more importantly, where to even begin to look because as I said, no user code is running.
This happens on only about 10% of our machines, but it consistently happens on those machines. All are clean (i.e. relatively fresh OS installs, no crazy apps, etc.) and mostly identical machines spec-wise: similar CPUs, similar RAM, same video drivers and service packs.
So as I stated in the title, can anyone suggest possible reasons why a WPF app would pin the CPU and lock the app on some computers but not others? We're just stumped!
Found it!! Turns out there's a bug in .NET 4.0 regarding UI Automation and the changes MS introduced. Here's the info, and the fix! (Note: Even if you call MS, they will send you a link, but it's always a broken link. I managed to track this down manually.)
Note: Their article talks about a specific case that causes this behavior, but if you google around, you'll see tons of issues around hangs related to those DLLs. The latest is they're promising a fix in the .NET 4.5 runtime (from a MS post on this issue.)
Here's the KB article...
http://support.microsoft.com/kb/2484841/en-us
...and here is the actual hotfix.
http://archive.msdn.microsoft.com/KB2484841/Release/ProjectReleases.aspx?ReleaseId=5583
Crappy video driver? Pull two machines - one where it happens, one where not, and start analyzing differences. Could be hardware defects, bad video drivers, anything in that area. WPF uses the GPU to render if one is there.
Since you seem quite to lack options, i would advice to make a new project with just most basic ComboBox in the Window, doing almost nothing. This should work (check :-) ). Then you add features one by one in the ComboBox and test, for instance when you add command, start with empty one. Do this until it 'breaks'. So you know which feature is the culprit.
You didn t say if all was working with software rendering.
I'm facing an extremely weird bug here and I'm not really sure If I'm following the right path to solving it or even how to solve it.
Here is the problem I'm facing: I start debugging a WPF application which uses log4net, NHibernate and LINQ to NHibernate, and when I try to get an Entity from the database my application and sometimes VS hang for a lot of time, and after a while an exception dialog opens showing a message containing the following information on a ContextSwitchDeadlock MDA:
The CLR has been unable to transition from COM context 0x34fc1a0 to COM context 0x34fc258 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this
I copied the code files to a new project and deleted the old project to see If I could make this message disappear, thinking it had something to do with my configuration. I started adding few things at a time to see what was causing it, and when I included log4net configuration code the bug appeared again. First I included it through AssemblyInfo and later trough code configuration on application startup, and absolutely nothing changed at all :(
So, here are my findings:
It only happens when I'm using log4net.
It happens when NHibernate loads an Entity from database (lazy loading).
I don't know what might be the source of this bug. It only happens when debugging in Visual Studio. I've tried following the steps on the "Enabling and Disabling MDAs" section of the following page: http://msdn.microsoft.com/en-us/library/d21c150d.aspx, but that doesn't work either, VS still hangs and it's memory usage increases.
When I run the program normally none of this happens, so I'm pretty sure this is not a deadlock situation, as this question suggests: contextswitchdeadlock (I've also tried the solutions posted there).
Because of that, I've decided to disable log4net and enable it again when deploying my app.
I'm posting this question to find out if somebody else has faced this bug or if somebody has some suggestions on how to solve it. Finally, it might help somebody else facing this very same problem.
When using the DebugAppender all the entities in the databases are loaded and all its data written to the debug output. That was causing the ContextSwitchDeadlock MDA since it tookmore than 60 seconds to run.
Disabling the DebugAppender solved my problem.
Thanks to Mauricio Scheffer for the tip.