For some reason, my Silverlight project in VS2010 recently started to take forever to load, upwards of even 10min or so. Sometimes it won't ever load as far as I can tell, and just hangs on the silverlight loading screen with the blue dots in a circle animation. But before it even gets to that point, it painfully spends a solid 10 seconds or so for each symbols file it loads. So in the output I'll get:
'WebDev.WebServer40.EXE' (Managed (v4.0.30319)): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Drawing\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Drawing.dll', Symbols loaded.
Then 10 seconds later I'll get the next one, and there's about 50 of them. The weird thing is that when I run the project with my internet disabled, it loads extremely quickly. Each one of those symbols loaded statements flies by, and before I know it I'm looking at my running Silverlight project. My teammate things it might have to do with Perforce, which is how we manage our source, and which we have a plugin for in Visual Studio.
Anyone have any ideas what could be causing this? Or experienced a similar phenomenon once? It randomly started yesterday.
Thanks!
Edit: I'm using the built-in VS Server to host my project, if that's relevant.
Resolved: We don't know exactly what caused the issue, but it was network related and fixed itself. I just hope it doesn't happen again.
You might be downloading symbols from MSDN or some other server. Check Option -> Debugging -> Symbols and make sure you don't have any locations active.
Related
I upgraded from 10.3 (Rio) to 10.4 (Sydney) (with side-by-side installs), now having IDE docking exception, e.g.
Loading the desktop from "C:\Users\gary.walker\AppData\Roaming\Embarcadero\BDS\21.0\Default Layout.dst" for doc host windows "DockSite3" failed with message:
"EAccessViolation: Access violation at address 50165CBF in module 'rtl270.bpl'. Read of address 33DEEBFF"
Deleting all .dst files has resolved the issue in at least one case (a coworker).
Also, when attempting to debug a program, I was having a hard failure during debug startup that prevented debugger use, before application began execution. I resolved this problem by copying my Default desktop to my debug desktop.
Another friend had pretty much the same issue and was able to fix it, unfortunately he does not know how he fixed it.
Question is does anyone know how to fix this?
I am still waiting for an answer from Embarcadero and this is causing us real problems at the moment.
I received an answer from Embarcadero support.
It fixed the problem for me until I adjusted my desktops to the way I wanted them and them - still better than nothing. I suspect there is no solid work-around at this point in time. But, this may work well as long as you are not frequently changing your desktop layouts.
There were display layout changes introduced in 10.4.1 that cause the errors that you are seeing.
Shut the IDE down
In Windows Explorer navigate to: %AppData%\Embarcadero\BDS\21.0
Delete the *.dst files at that location (you can back them up first if desired)
In Windows Explorer navigate to the product's \bin directory. The default location is: 4. C:\Program Files (x86)\Embarcadero\Studio\21.0\bin
Copy the three default *.dst files from this location to the location in step 2
Start the IDE as normal
Good morning.
I wanted to expose the problem that I have, when running my application on a cold boot (right when restarting the pc) on certain machines it becomes slow so that the main application screen appears, like 12 seconds.
Then the second time you start it, it works fine.
More data:
- WPF application desktop windows in C #.
When running the application the splash screen appears instantly, and the login windows screen appear in 2-3 seconds (this is acceptable).
When you type in screen login the user and password and it is accepted is when it is slow and it takes 12 seconds to appear in the main menu. (In cold start then the next times you go and go normal).
So I doubt that it can be, the code does not do anything exceptional:
1.- Could it be a problem in the connection to the local sql database?
2.- Could it be the structure of the solution? I explain, the program is inherited from a partner and is composed of a solution with 5 projects inside.
- Backend.UI (where are the visualization forms and functionalities)
- Business (where it puts the BLO)
- Data (where you put the DAO)
- Domain (where it places the entities)
- Resources (Resource Files)
Is this structuring correct? Would not it be better to put everything in a single project separate each thing with your folder?
I say it by the following, analyzing with the debug I see that until the first login screen only load:
(CLR v4.0.30319: DefaultDomain): Loaded 'c:\Prueba\xxxx.BackEnd.UI\bin\Debug\xxxx.BackEnd.UI.exe'. Symbols loaded.
And once accepted the login to the main menu (here is when it is slow, 12 seconds) loads the other modules.
(CLR v4.0.30319: xxxx.BackEnd.UI.exe): Loaded 'c:\Prueba\xxxx.BackEnd.UI\bin\Debug\xxxx.Domain.dll'. Symbols loaded.
(CLR v4.0.30319: xxxx.BackEnd.UI.exe): Loaded 'c:\Prueba\xxxx.BackEnd.UI\bin\Debug\xxxx.Business.dll'. Symbols loaded.
(CLR v4.0.30319: xxxx.BackEnd.UI.exe): Loaded 'c:\Prueba\xxxx.BackEnd.UI\bin\Debug\xxxx.Data.dll'. Symbols loaded.
Can this be the problem? That having several projects (which I do not think need to have them separated) have to load them and that takes time ....
Remember that this slowness is only in the first charge after starting the machine, then everything is fine.
But 12 seconds I see too much.
Thank you in advance for any comments.
It does take time to load and JIT a .NET project on first start. Multiple libraries might take more time if your hard disk is really, really slow.
I would guess that with a modern HDD, if you put all your code into one single executable, your program will take the same amount of loading time on a cold start, just once at the start, instead of later, when the library is loaded.
But you could just try it. Move all your files over to your executable project and test it.
Generally speaking, the Just-in-time compiler (commonly called Jitter) will compile your IL (Intermediate language) code to native code when you start your program. Through various caches on different levels, this will be faster when you do it more often. As the Jitters strong suit is compiling your IL to exactly the specification of your system, a cold start clears all those caches. After all, a cold start is when you system could really have changed (you could have insterted more RAM, a different processor, etc). So yes, it is normal that it takes longer to start your program the first time.
If your specific starting time can be optimized is something that only you can check. Use an profiler.
Observed behaviour (everything here is on Windows 10):
I run Visual Studio (tried 13 and 15, both behave the same) logged into user A
After starting up, VS takes virtually no CPU time (<1%)
I log into user B, without signing out of A
VS imediately starts using A LOT of CPU time (~25% on my 4 cores with hyper threading)
I can go back and forth between A and B, and it goes back and forth between low and high CPU usage
This is all without any projects or files opened, though it also happens in that case.
I noticed this because I was originally investigating similar behaviour of a WPF application (after a user reported this issue).
While trying to isolate the problem, I found that even a completely new WPF project, with just a single empty window, behaves exactly the same (whether or not run through Visual Studio).
Through profiling and debugging I found that the app seems to spend a huge amount of time handling windows messages.
Specifically I found that it seems to be almost exclusively WM_PAINT messages (we are talking easily hundreds or thousands of messages per second - as many as the CPU can handle it seems).
No other programs I have running (chrome, skype, sublime text, ..) behaves this way.
Has anybody else seen this kind of behaviour?
And/or any ideas what could cause this, or how I could investigate this further?
Naturally, I cannot fix Visual Studio (unless the problem is with my setup somehow) but I hope there is something I can do about my WPF application.
As per Hans Passant's suggestion in the comments, I reported this problem to Microsoft here:
http://connect.microsoft.com/VisualStudio/feedback/details/2390593/wpf-apps-use-a-lot-of-cpu-time-when-logged-into-different-user
As it turns out this indeed seems to have been a bug in WPF, which is fixed in the current version of Windows 10 (probably specifically since the Anniversary Update (version 1607)).
Hence the solution: Make sure to update your OS.
I just discovered this problem today, and I had no idea what caused this problem. My project had been developed for few months.
I have a project(solution), with several projects in there, it works well if I write and debug, by pressing F5.
The problem occur is when I press Ctrl+F5 (to skip debug mode), or run directly from double click the exe, it crashed. The errors dialogs that pop up every times are different, but OutOfMemoryException is the most frequent one.
I had checked to make sure all my projects are .Net 3.5
I put a MessageBox.Show("something") at the beginning of my main project constructor, but it never reach.
I use some registry cleaner to clean/fix my registry, scan for viruses.
I had try to read the meaning of each error and exception, but still no clue why it happen.
These are a series of screenshots if I press Ctrl + F5. (FutureGenerator is some random name I gave to my project.)
Series of screenshot if I run the app from my debug folder, FutureGenerator.exe
I suspect this is caused by framework crashed during Windows Update, but I removed those update that I performed recently, still same. The exe file works on other non development PC, but I don't want to reformat my PC or reinstall my VS, yet, because it's a painful process.
Any idea, anyone?? Million thanks.
You mention v3.5 but the very first screenshot is about v4.
Try repairing your Framework 4 and/or VS2010
I found the problem. It's actually because I added FutureGenerator.exe into Application Verifier by Microsoft. The verifier only support debugging testing.
After I removed FutureGenerator.exe from the Application Verifier, everything's ok.
I am kind of lost here, and I don't know what to do
I have a problem that I don't know what the source of it.
We have a large wpf application, that is built similar to prism (composite application)
Actually we are using lots of prism library.
I wrote a module to replace an existing module.
And the application now is loading my module, instead of the old module.
I start to notice, with the new module, that sometimes the application freeze for 20-30 seconds without any response, and then it work smoothly after that.
The freeze is not consistent, and there is no pattern or a specific reason that cause it.
I am suspecting that could be my module that is causing that freeze.
But at the same time, many other developers introduced new code to the application.
My question is there a way to trace that freeze?
Is there a way to compare the old module and the new module that I wrote?
I can run the application with my module, and trace the application, and then I can change the config file to load the old module.
Is there a way to compare between the two?
Should I do profiling?
and if profiling will help, then what should I look for?
any other tool could help?
Thanks a lot for any reply
It sounds like you are doing a long running operation on your UI thread. Are you making any database / webservice calls from the main thread? I think one of the easiest things to do is run it in the debugger, and when it freezes, hit the "pause" button. Visual Studio will pause execution at the current location, and you can examine what is taking so long.
If the problem isn't immediately obvious there, I would definitely start profiling the application to track this down.