Trying to profile my command line application in VS 2017 on a W10 machine with April 2018 Update, VS fails to create the report.
The UI says Microsoft Visual Studio was unable to create a diagnostics report. Check Output window for errors.
The Output window says
Profiling of 'Program' started.
Program has exited.
Profiling of 'Program' stopped.
Diagnostics session stopped with errors.
Merging of ETL files has failed (0x80070070) (Flags: 0x0000011f).
Previous search gives little answers as to why, but the problem seems related to Windows' event logging service. Comments on this similar question suggest it's related to disk occupation, but with no source. My SSD is indeed almost full, but with 6 GB of free space.
I resolved the issue, the multiple times it happened, by restarting windows and then start the profiling as first thing as the OS is ready. On a fresh start it works, but going further with changes and profiling it eventually appears again.
If someone knows a long-term solution feel free to add.
Code 0x80070070 "There is not enough space on the disk." Your disk was full, or became full during a build or other operation as temporary files were created.
Related
I am using Visual Studio 2015 Community. Problem is when I start VS2015 it start quickly but when I open website project then it takes too much time apprx (30-60 mins) to open particular code file (Only for first time). Once it loads then it works normally. How do I resolve this problem?
It's very difficult to give an correct answer without more details as there might be a lot of things that can happen but I suggest you check the logs from Process Monitor.
It will log all the events that happening in your OS.
After gathering the logs you need to go through them (try to filter them - there might be a LOT of them) and check for some indications of WAIT operation.
Maybe some network operation is time-outing (but 30-60 min is quite huge timeout) or some IO operation.
Yesterday, I sent my computer to sleep but kept VisualStudio open, together with my solution. Which is the most likely cause for the following problem:
When I first tried to browse my still-open solution this morning, I got "Visual Studio is waiting for an internal operation to complete." I gave VS like 10 minutes, but nothing changed. The processor load is 5%, disk load close to non-existent, memory consumption normal.
So I went for taskmgr, took good aim and shot VisualStudio down.
When I now started VisualStudio again and tried to open my solution, it would stall again during opening, with the same error message. So I killed VS again, then rebooted my PC. But, you guess it, when opening my solution after that, it stalled again.
I googled for the error message, but the problems/solutions I found were mostly wrt debugging. I am quite sure that I didn't send a running debugging session to sleep yesterday. Also, the rdpclip process isn't running. Furthermore it only happens with this solution - I can create new solutions and projects and work with other projects.
I already replaced the sln file with a backup, but it didn't help. I did not find "new" files (changed today or yesterday) in the solution directory, apart from some cs files and the compiled DLLs.
So now I am at the end of my knowledge. Is there any leftover "lockfile" somewhere in the Programs directory, which I should delete to be able to work again?
EDIT: I just stopped the last attempt to let it run through. The "operation", whatever that is, was not finished after more than 2 hours.
Have you ever experienced a slow linking process in a C++ project compile (I'm using VS2013)? I get linking process taking 15 minutes after a 5 minutes Build. A Rebuild or Visual Studio restart does not fix the issue.
Task manager shows mspdbsrv.exe taking a full core (25% on a 4-core), and pdb file creation is very slow, Kb after Kb it reaches 50 Mb.
Additional info:
the same project on another computer build and link in acceptable time.
antivirus is disabled
I've tried changing the pdb file creation location: no success
I've set the linker output Verbose, but it stops at one debug row and then wait all the time there.
VS2013 is updated to SP4
Hard disk activity led on my laptop is mostly turned off, so there's no full activity on the disk.
I'm running Windows 7 Pro.
VS2013 is run with administrator rights
Thank you.
Fixed changing "Debug Information Format" from /ZI (Edit and Continue feature) to /Zi. I still have no clue why this cause a slow linking only on a specific computer and not for the others. Hope this could help people coming here for the same issue.
Is it using Link-Time Code Generation? On VS2010 that step was single threaded so it takes much longer than the apparent compile step. On later versions this step was improved to be multithreaded, according to blog posts. It also mentioned that PDB access is a bottleneck. So, maybe you have an old mspdbsrv.exe on that system? Look at the version info on the file, compared across machines. There might also be some option to control its locking and multi-use behavior, hidden away someplace.
I get the Microsoft VS Delay Notification pop up consistently when I am trying to attach the debugger to a remote process (Native only, with no authentication). The process runs as a service on the remote machine, but Visual Studio (2005) seems to have no problem with that when it's running as a service locally.
I've loaded the symbols correctly (as in specified the right directory under Tools\Options\Debugging\Symbols), but this doesn't seem to help.
I've tried starting VS 2005 in Safe Mode, but that doesn't seem to make a difference either.
I had the same issue and used ProcMon util to look at waht my devenv were doing.
In my case it was waiting for loading symbols. So you you should check your Env. variable _NT_SYMBOL_PATH and if there is cached symbols if no - all this time your VS is waiting for downloading it.
One possible solution is you have many currently set or lingering (invalid) breakpoints.
Try clearing all the breakpoints and see if it helps.
There are more possible solutions here:
http://connect.microsoft.com/VisualStudio/feedback/details/498240/microsoft-visual-studio-is-waiting-for-an-internal-operation-to-complete
Hope this helps.
I've just had this problem when I turned on both native and managed debugging on a single application.
Turning off the native debugging fixed the problem.
The one thing that helped me is updating the package. Open the solution that is having this "waiting for internal operation to complete" then Go to Tools - Nuget Package Manager - Package Manager Console. Then run "Update-Package". After the update, I was able to close and open the solution with no problems. Hope this helps your issues.
I had the similar problem and it occurs because of the variable expression I created.
For example:
variable1 = variable1 - variable2 (gets warning)
variable1 = variable2 - variable3 (No Issues)
I had the same problem, did a lot of googling tried several things but didnt solve the problem. Finally I used processexplorer to check the devenv process and found there is a child process for devenv.exe, it was cmd.exe and it has another child process node.exe. So I went to Programs and Features and uninstalled Node 1.1 VS 2013 extension and Node package manager. It took quite some time to uninstall it even though I am using i7 quadcore processor with 16 GB RAM it took almost close to 1 hour to uninstall these two sofwares from my laptop. And this solved the issue.
Has anyone had and solved a problem where programs would terminate without any indication of why? I encounter this problem about every 6 months and I can get it to stop by having me (the administrator) log-in then out of the machine. After this things are back to normal for the next 6 months. I've seen this on Windows XP and Windows 2000 machines.
I've looked in the Event Viewer and monitored API calls and I cannot see anything out of the ordinary.
UPDATE: On the Windows 2000 machine, Visual Basic 6 would terminate when loading a project. On the Windows XP machine, IIS stopped working until I logged in then out.
UPDATE: Restarting the machine doesn't work.
Perhaps it's not solved by you logging in, but by the user logging out. It could be a memory leak and logging out closes the process, causing windows to reclaim the memory. I assume programs indicated multiple applications, so it could be a shared dll that's causing the problem. Is there any kind of similarities in the programs? .Net, VB6, Office, and so on, or is it everything on the computer? You may be able to narrow it down to shared libraries.
During the 6 month "no error" time frame, is the system always on and logged in? If that's the case, you may suggest the user periodically reboot, perhaps once a week, in order to reclaim leaked memory, or memory claimed by hanging programs that didn't close properly.
You need to take this issue to the software developer.
The more details you provide the more likely it will be that you will get an answer: explain what exact program was 'terminating'. A termination is usually caused by an internal unhandled error, and not all programs check for them, and log them before quitting. However I think you can install Dr Watson, and it will give you at least a stack trace when a crash happens.