I ran Visual Studio 2012 performance profiler tools via command line and ran into the below issue and spent hours to figure out the issue.
VSP1812: This report contains no process information.
The error was due to the fact that one of dll and pdb were not of the same version.
Related
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.
Has anyone successfully used MS HTML Help Workshop on Windows 10?
I have run into a problem when I try to compile a package which has not caused any trouble on Window 7 for several years.
On Windows 10, the processing apparently never terminates, although it uses only less than 1% CPU after the first 10-15 minutes. I have to kill the processing. A CHM file is produced, but it can't be opened. The file is twice the traditional size: 1,2GB instead of ~600MB.
No problems so far with HH on Windows 10. The file size should be nearly the same as compiled on Windows 7.
I'm assuming your old project has been compiled without any problems under Windows 7. And I think you don't have further tools like e.g. RoboHelp in use and compile it the man's way using Microsoft HTML Help Workshop.
I'd recommend using MJ's Help Diagnostics Version 3.0.5.96. It's a small utility that reports if all the HTML Help runtime & Workshop (compiler) DLLs are installed and registered to the correct locations. If you have compiler crashes, and crashes when simply opening a CHM, or when searching from the CHM search tab, then this utility will help sort out rouge DLL problems.
Download and unzip the utility to a folder with write permissions. You may have to do a right mouse click to MJsDiag.exe and check UnBlock. Run the MJsDiags.exe and generate a report. Important information is highlighted.
If you see errors reported re-run MJsDiags as an administrator and use the "Register Help DLLs" page fix registration errors.
I know there is a lot written on the topic, but nothing seems to help in my case. I keep getting lnk1168 error whenever I try to run a solution. exe appears in Task Manager and can not be closed with TM or Process Explorer. Applicaton Experience configuration has no effect either as well as reinstalling VS (I've already tried 2015 and 2012 versions)
When I run command line application (executable generated using visual studio 2008) on non development windows 7 machine it gives following run time error "application has requested run time to terminate in unusual way. Please contact application support team for more information". It runs fine on a development machine.
With VS 2005 and VS 2008, Visual C++ used a side-by-side versioning scheme that requires manifest entries embeddded in the EXE to really work correctly in all cases. It's possible you are dealing with one of these. See these articles for details on debugging these side-by-side issues.
Diagnosing SideBySide failures
Part 1: Troubleshooting VC++ Side by Side Problems
Part 2: Troubleshooting VC++ Side by Side Problems
Note that with VS 2010 and later, Visual C++ no longer uses this side-by-side scheme. That said, there are still lots of reasons to use embedded manifests anyhow. See this article.
I followed the instructions in this link: http://msdn.microsoft.com/en-us/library/bt727f1t.aspx to install the remote debugger (2012) on my server where the application is running in hope to debug it remotely from my dev machine running visual studio 2012.
I cannot even get as far as viewing the list of processes to attach to on the remote machine. I keep getting "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named [name]. Invalid access to memory location".
I have managed to successfully connect a few times but then the attach fails immediately then I cannot connect again.
This is causing huge issues for me as I cannot remote debug anything. I must be missing something glaring. Please someone give me a solution.
I've found the only way to correct this is by restarting Visual Studio.
Worked for me. I found it at this blog post about invalid access and remote debugging.
It turns out the one thing I missed was to tell Visual Studio where to find the .pdb symbols relating to the remote process. To do this go to Tools -> Options -> Debugging then in the Symbol (.pdb) locations add the remote location to the pdb files.
To clarify, I was attaching fine but could not break into code. Now I can. Be aware though that there are other hurdles before you get to my stage where I was attaching to the process successfully but could not catch a breakpoint.
I recently had someone else report this and debugged the issue on their machine. The "Invalid access to memory location" errors are due to an issue in Windows, it can be addressed with this hotfix.
I have had this problem in VS 2012, 2013, 2015 and 2017. Based on other answers it is likely that the problem is related to running a 32 bit version of Visual Studio on a 64 bit PC. Sometimes, as others have recommended, restarting Visual Studio fixes the problem but the best solution I've found so far is to start Visual Studio without a solution, open Debug -> Attach to Process, change the Connection Target to the remove server and wait for the process list to load. Then Cancel, do not attach yet. Load your desired solution and then come back to Attach to Process and the remote process list will still be loaded. Connect to your desired process and everything should work properly from then on.