I am using WinForms, Visual Studio 2013, .Net 4.5
When running my application through the Visual Studio Profiler, it works exactly the way it should and when running it through either Debug or Release mode, I face horrible freezing and repainting issues.
What is the difference between running your application in the Visual Studio Profiler vs. running in through the Release Mode?
Thank you in advance
Finally found the answer here:
Why does my program run way faster when I enable profiling?
When you run your application within Visual Studio, the debugger is attached to it. When you run it using the profiler, the debugger is not attached.
If you press F5 to run your program, even with the Release build, the debugger is still attached.
Since I was running my application through Visual Studio, I was seeing some really strange behavior such as slow repainting, freezing, etc. - I spent days chasing the usual suspects, double buffering, not invoking calls from background threads, missing locks, etc. and it turns out I was chasing a bug that wasn't there on a first place. Hope this saves someone hours or headache.
Related
I was happily debugging some C# code in Visual Studio 2015 when I started to notice that a VsHub related process (Microsoft.VsHub.HttpHost64.exe) was going bananas with memory consumption and slowing my whole system.
and even after I close the application I was debugging and Visual Studio it still was consuming memory.
This keeps happening and makes debugging with Visual Studio a little bit frustrating... when this stuff is consuming more than twice the memory your own program is allocating.
Anyone having the same issue and solve it (without deleting/renaming the executable)?
Any thoughts?
I use unmanaged dll with P/Invoke in this app, and I always tested it inside Visual Studio (with debug mode on x86 CPU because the dlls are only x86), and it works just fine. But when I just start the exe manually after some time (probably at the first operation with those dlls, but I don't know exactly) it says the exe has stopped working, and it starts checking for solution (I use Visual Studio 2013 on Windows 8.1, if that matters). I tried to add the dlls to the project as existing item, but that doesn't help. Also I know, that it's not because it can't find those dlls, cause if I delete them, it doesn't crash, just freeze without any error message. Shouldn't it work the same from Visual Studio as manually started?
There is also a weird bug when I run from Visual Studio: everything's work fine, but sometimes Visual Studio just suddenly stops debugging, as if the program were closed and the GUI of my app freezes, and I can only close it by closing Visual Studio (as I close it, the GUI disappears). Maybe it's a totally different problem, but it can be connected.
Edit:
Here's the project on github, if somebody could check it:
https://github.com/geiszla/CycriptGUI
Some news: If I run it with Ctrl+F5 it also crashes. What's the difference between F5 and Ctrl+F5, that can cause this problem?
Searched all over Google with no real simple answers. Here it is folks(at least it worked for me and is simple):
When you run the console app in Visual Studio, look at the output window at the bottom, get the location of the ..\bin\Debug\*.exe
Copy the *.exe and the *.config to your desired folder, run it, it should work the same way in Visual Studio.
Thanks for every help, my problem was solved: I called an unmanaged function with only 2 parameters, while it had 3. However I still don't understand why it worked with debugging mode, and not without debugging.
I've been working on an intermediate-sized project in Visual Studio 2013 in C#/WPF. It relies on the Kinect SDK, and there are a good number of objects implemented in the code. When I run the debug cycle the first time (using the release configuration), execution is pretty speedy. On subsequent runs, the execution (especially of the code to connect to the... erm... Kinect) slows down significantly. I was wondering what could cause this, and what I could do to diagnose it. Are there any benchmarks in Visual Studio or things I could do to make the slowdown go away?
The debugger is hanging intermittently but frequently for no obvious reason. It times out eventually and recovers.
I am using vs 2010 Microsoft Visual Studio 2010 Professional 10.0.30319.1 RTMRel, running a 4.0 client app on a Vista 64 o/s.
Has anyone else been having this issue too, and have a fix?
As a related aside, anyone know if there are any service releases yet??
Cheers,
Berryl
Well, in 2005 and 2008 this happens all the time as well. Usually it has to do with (a) loading symbols from a public symbols server (yeah network I/O on the UI thread!), or (b) intellisense, or (c) you're debugging the network stack (or some other OS component) and Visual Studio is trying to use it (and things deadlock). If (b), wait for it to finish doing its thing before you start debugging. Sucks up front, but saves you time and frustration in the long run.
There are no service packs for Visual Studio 2010 yet. I've also had problems in the debugger, and sadly the best advice I can give that has worked for me is to exit Visual Studio and re-open it.
I just migrated to Windows Ultimate 64 SP1, because my system's hard drive crashed. I installed Visual Studio 2005 SP1 and all the patches that Microsoft has recommended. I finally got my source code from my SCM, but now debugging does not stop on any of my breakpoints I have set. This is just a plain Winforms app, nothing fancy.
The first thing I did was to change the build target to x86. No dice. Then I went and downloaded Debugging Tools for x64, still no dice. I set the debugger to break on all exceptions both handled and unhandled. No dice either.
I've been looking at Google search results, but no luck there either. I've been at this for 3 days now with no luck. Has anybody dealt with this issue before?
Update:
The projects are all set to Debug (x86).
Breakpoints stay normal when the debugging session starts.
I already did a re-install, and that didn't work either.
I am running as Administrator and turned off UAC.
I attached to the project using "Attach to Process", and I was able to step into the code that way. I'm hoping to find out why it is not auto attaching, in order to avoid having to do this manually every time.
This is listed as a known issue for VS2005 on Vista (Via MSDN):
Title: Just-In-Time (JIT) Debugging of
an elevated process will fail
Description: Elevated processes cannot
be JIT Debugged by VS 2005. This
includes system processes, such as
IIS, and applications started by
selecting ‘Run as administrator’.
Workaround: The debugger must be
attached manually before the debugger
will catch unhandled exceptions or
user break points
(System.Diagnostics.Debugger.Break,
__debugbreak, etc).
Couple of questions.
When your code fires up, does the breakpoint become an empty circle with a tooltip that indicates that the breakpoint won't be hit? Or does it become a full circle with a tooltip that indicates the process it's attached to?
You can try manually attaching the debugger to see if you get any traction that way. Just fire up the app and once it's running, go to the debug menu and choose "Attach to Process" - select the process that your app is running in and click "Attach".
I run Vista64 w/o issues - VS2008, though.
I am using Visual Studio 2005 with the same patch level on both Windows Server 2008 x64 and Vista x64 SP1 without any issues.
Are you running it as admin? When all else fails, try uninstalling and reinstalling.
Insure that the project is set for a debug compile and not a release compile, as the release compile doesn't contain your debug information.