I have a C++ application (it's built using Qt 5.8 library and works with PostgreSQL 9.5 database in case it's relevant). The application is build by MSVC 2012 compiler, is 64-bit application and both debug and release versions run normally on their own and under cdb debugger.
When I try to profile the running application by Visual Studio instrument (Analyze -> Profiler -> Attach), it seemingly hangs as soon as it tries to do something meaningful: simply resizing a window or clicking on checkboxes works, but any attempt to compute new values and write them to database never succeeds, as if control flow didn't return from some call.
When I stop the profiling, Studio marks as a "hot path" sequence of calls RtlWalkFrameChain->RtlpWalkFrameChain->RtlpLookupFunctionEntryForStackWalks->RtlLookupFunctionTable->RtlAcquireSRWLockShared.
RtlpWalkFrameChain has the biggest "exclusive samples" count.
Trying to filter data to exclude initial several seconds of run (until the apparent freeze) results in "No Call Tree Data Is Available" message.
I didn't manage to find any article or post with a similar problem.
The project is build in Qt Creator (I don't have a project file Studio would understand, so I can't run "normal" performance analysis).
OS is Windows 7, exact version of Visual Studio is 11.0.61219.00 Update 5.
Any idea on the subject would be welcome.
Upd: When I try to profile the application with Luke Stackwalker profiler, it aborts with the message ERROR: StackWalk64-Endless-Callstack!. The only relevant comment about the message I found is this Stackoverflow question. When I run application under cdb debugger and then try to profile it with Luke Stackwalker, the error message is the same, but subsequent pause in the debugger shows the proper (or at least believable) stack for all threads. For the working thread debugger points to a line of code inside system library and doesn't advance no matter what I do (once again, without profiling attempts the application runs normally, debugger or not).
Related
I'm trying to get started with microsoft's azure sphere development.
When I try to debug any of the starter projects within vs code, it tells me that I have a breakpoint set on the first line of the app.
However, vs code doesn't show any breakpoints in the "Breakpoints" tab.
I am running the latest VS code version (1.44) with the Azure Sphere Extension 20.1 on windows 10. The same problem appears on Linux.
To reproduce the bug:
Download the starter projects from github
Install the Azure sphere extension for visual studio code.
open HelloWorld_HighLevelApp folder in azure-sphere-samples\Samples\HelloWorld\HelloWorld_HighLevelApp in visual studio code.
Go to the Debug tab and hit the green play button on top left corner. Next to the button it should say Launch for Azure Sphere High-Level Applications (gdb)
For me it doesn't an error but the output console shows:
Deploying image...
Starting debugger....
Process /mnt/apps/1689d8b2-c835-2e27-27ad-e894d6d15fa9/bin/app created; pid = 2233
Listening on port 2345
Remote debugging from host 192.168.35.1, port 54911
Starting CMake Hello World application...
The Debug Console shows:
...
Breakpoint 1, main () at ../../main.c:45
45 {
Loaded 'target:/usr/lib/libapplibs.so.0'. Symbols loaded.
Loaded 'target:/lib/libgcc_s.so.1'. Symbols loaded.
Loaded 'target:/usr/lib/libc++runtime.so.1'. Symbols loaded.
Is there a work around / a plan to fix the issue?
Addition 1:
To provide extra clarification here is a screenshot, showing the miss match of console output (breakpoint set) and ui (no breakpoint set)
Azure Sphere uses gdbserver to provide a debug channel to the device. A default behavior of gdb is to break on entering main. This can be confusing to people on Windows who expect a run to breakpoint behavior as is common in Visual Studio. For our interface with GDB we intentionally silently skip the breakpoint on entering main in Visual Studio to be consistent. You can actually see that breakpoint skipped in the debug log output window.
For VS Code we also skip the breakpoint on main when you are on Windows. It looks like you are on Linux from the output above. I haven't used it on Linux for a few weeks so can't recall if the behavior is intentionally different there or not. It would make sense to me to break on entering to main when on Linux as that is the common expectation when using GDB which is more common there than on Windows. I'll check if this is by design or not and reply back, but I suspect it is.
Solution:
Finally I found the root cause of the issue. Visual studio code acts just slightly different when debugging the sphere device compared to just plain c code.
When you start the debugging mode and you haven't set a breakpoint initially, it won't start running your program till you have set a breakpoint. In plain c debugging the program just runs through and printed values are shown in the debug console.
For over a month now I've been experiencing problems with VS2017 on my home PC. I even tried submitting the feedback to Microsoft. There's more info about the problems I'm experiencing there.
The problem:
The gist of it is that VS is eating RAM like crazy. As soon as I start opening files, adding new files, using IntelliSense, building or (especially) debugging, the RAM usage skyrockets.
After that it's only a matter of time before the VS crashes and restarts without any error message. Though there are numerous error messages throughout these breif ~20min I have with each session.
Additional details I observed:
Doesn't happen with Python projects, as these don't have to be built constantly. It might be eventually happening if you debug a lot, but I didn't have the chance to check that because most of my Python coding is debugged on an external device
Size of the loaded solution doesn't matter;
UWP and WPF seem to crash the most. Console Projects take longer to crash.
Also affects .NET Core;
It doesn't matter which version of .NET Framework I use;
VS2015 worked perfectly, but I don't have it anymore after the format
What I already tried:
I reinstalled VS;
I refreshed Windows;
I reinstalled Windows;
I checked my drives and RAM for issues - none found;
I switched from Community to Enterprise;
I tried disabling extensions;
I applied some shady hotfix I found somewhere;
Finally, I installed Rider which seems to be the best solution as of now. It still lacks many important features, though.
Is there anything else I can do/try/check? Did anyone experience (and fix) a similar issue?
Cheers!
You get a System.OutOfMemoryException, this means your Visual Studio runs out of free virtual address space (4GB on 64 Bit Windows for the 32Bit Visual Studio because Visual Studio is configured to be large address aware and MS refuses to release VS as 64Bit program which would fix this issue).
To analyze the memory usage, you need to run WPRUI.exe (part of Windows Performance Toolkit (which gets installed by VS2017) for some scenarios, if not, install it on your own), select Reference Set (Note: expand the Resource Analysis entry first to see all options).
and click on Start. Capture the memory usage grow for some 100s of MB and click on Save.
Open the generated ETL with the analyzer (WPA.exe) and analyze what the process devenv.exe is doing.
Also zip the ETL + NGENPDB folder (important) as zip and attach it to your bug report so that Microsoft can analyze it.
I am having trouble getting builds to complete when they are set to run Dotfuscator on files. My environment is Visual Studio Professional 2012 paired with Team Foundation Server 2012, thus I am using Build Definitions and the Microsoft Team Foundation build architecture (build controller, build agents, etc).
My problem is that when I launch a build definition in Release config, which is set to run Dotfuscator Professional on my output files, the build hangs (either that or runs for so long that I have yet to see one complete). The log file shows that it is hanging during the build process template activity "Associate Changesets and Work Items", and task manager on my build server confirms that at this point Dotfuscator is running with huge CPU and memory requirements (around 50% CPU and I've seen near a gig of memory required). Here is the latter portion of the build log...
Find Property Values
CurrentLabel =
LastLabel =
Result = (Collection)
UpdateWorkItems = True
Final Property Values
Condition = True
Final Property Values
Condition = True
The last lines are duplicated on purpose, this is exactly what the log reads. This is where the build hangs and Dotfuscator is still running on the build server.
And here's the interesting part, when I do a local build on the build server (right click on solution, click rebuild) the build runs great, done in under a minute Dotfuscator and all. This suggests to me that something is going on between Dotfuscator and Team Foundation Build. Possibly something to do with the Build Process Template and/or Build Agents? I'm not much of an expert on Team Foundation Build other than the work I have done getting to this point.
Any ideas on what I can do to get Dotfuscator to run faster or correctly (depending on the cause of my error)? All help is much appreciated.
First off, I think I've been to every website and forum there is that's discussing this issue and I've tried many different things. I'm at my wits end. This is the dumbest thing and I just want to start coding again!
I'm using Visual Studio Express 2012 for Windows Desktop. I have a x64 project I'm trying to run in Debug mode using the local windows debugger. The only external library I'm using is that of which is required to run DX11.
I attempt to run my program and it freezes. A window pops up saying "A remote operation is taking longer than expected."
I click Terminate and another window pops up asking if I'd like to terminate the remote session. Why yes, I would.
Then it says, "Unable to start program (my path leading to my .exe). The network connection to the Visual Studio Remote Debugger has been closed."
To my understanding, because Visual Studio itself is a 32 bit application, it needs to use the Remote Debugger to compile to x64. Is that correct?
Regardless, I'm still failing to see where that would break down. I've ran several repairs on VS and upgraded to Service Pack 2 (or 1, whichever is the latest).
I've ran a windows repair and uninstalled any VMWare type stuff on my computer. I'm not using a VPN.
I've even copied msvsmon.exe from my laptop (working instance of the project) over to this computer and still no luck.
I'm about ready to Nuke my OS and do a clean install on everything. sigh
Found the problem. It wasn't Windows Firewall like other threads describe. It was my internet filter. I guess it decided to try and block msvsmon.exe because it was using the network. Adding it, along with WDExpress.exe to the application exceptions list did the trick.
I've written what should be a very simple unit test using the Native Unit Test project in Visual Studio 2011 Beta. The test builds and fails (not unexpectedly), and I need to debug it. When I try to launch the test under the debugger, the debugger never starts, and instead presents this dialog which lingers indefinitely:
Anyone know what might cause this? I've never had this problem with previous versions of Visual Studio.
Update:
I've opened an MSDN thread on this: http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/db3213f8-9658-4470-9e3f-3b67ec954fae
I also opened a connect bug (which apparently was just summarily dismissed): https://connect.microsoft.com/VisualStudio/feedback/details/735369/debugger-wont-start-for-native-unit-test#details
I would need to know some more information regarding this issue but it seems like it is possible that the DebugAttachProcess() method in windows isn't returning which can happen in the case that you do not have enough permissions to do so... make sure you run VS as Administrator, also, you can try to debug it in ollydbg to see if it is an executable problem, although it wont give you the source (you're stuck in assembly).