I am trying to profile a Web application(Debug->Start Diagnostic Tool without Debugging) but every time it is failing with below message. Solution is set in release mode. After start profiling IE is opening with a URL http://localhost:19394/ but getting 'Page cannot be displayed'.
Warning VSP2013: Instrumenting this image requires it to run as a 32-bit process. The CLR header flags have been updated to reflect this.
Launching web server with profiling.
Launching profilable project.
Data written to C:\Project\Report150826(1).vsp.
Profiling finished.
File contains no data buffers
File contains no data buffers
Analysis failed
Profiling complete.
I am using VS 2015 Enterprise RTM and it is running under administrator privileges.
Tried to uninstall Visual studio using the command line "C:\Setups\Visual Studio\VS 2015\vs2015.ent_enu\vs_enterprise.exe" /uninstall /force but uninstall also failing with error message:
Update for Microsoft Windows (KB2999226) : The storage control blocks were destroyed.
Related
I am trying to profile my application using the built-in profiler in Visual Studio 2017:
However when I close the application, this is what appears:
This is what I see in output window:
Profiling of 'MyProjectName' started.
MyProjectName has exited.
Profiling of 'MyProjectName' stopped.
Diagnostics session stopped with errors.
Merging of ETL files has failed (0x80071069) (Flags: 0x0000001f).
What's wrong? I am running MS Visual Studio Community 2017 on Windows 7 x64. I am profiling C++ Qt application.
I had this issue with that exact same error code 0x80071069. I noticed my WMI Performance Adapter Service (wmiApSrv) was stopped. Starting it back up resolved my issue and I was able to successfully profile my application.
In the past I had seen a similar error caused by my C: drive running low on space due to the size of the temp trace files. Make sure you have plenty of free space in your C drive as well.
I am currently trying to build a simple Win 7 x64 USB driver using this guide: https://msdn.microsoft.com/en-us/library/windows/hardware/hh706187(v=vs.85).aspx
Host is using VS2013 & WDK 8.1
Because I don't have a null-modem cable (or any other means of setting up a debugger connection between host and target), I just filled my settings with the default ones found here, expecting some sort of error to return, but the configuration process went through without a hitch, displaying
WDK Remote User Account successfully created
Installing .NET Framework 9possible reboot)
Installing VC Redist (x64)
Installing test automation (x86)
Installing test automation (x64)
Installing debuggers (x86)
Installing debuggers (x64)
Installing driver test framewok
Registering logging components
Configure debugger settings (x64) (possible reboot)
Configure computer settings (x64) (possible reboot)
Creating system restore point
Complete
So I assumed that what I assumed about serial/com ports to be wrong and continued to attach the WKM Debugger to 'Kernel' of my target computer, which was listed under the "Available Processes" datagrid. When I click the 'Attach' button, however, I get an error that says:
Windows Debugging Extension for Visual Studio
Could not start debug session, error 80070002: The system cannot find the file specified
I've tried Building/Rebuilding the project many times, and Provisioning the target computer also multiple times to the same results. I saw that question number 25776839 also had the same issue as me, but he mentioned something about changing VS's default from Kernel Debugger to Remote Debugger, which I'm not sure how that can be accomplished, but also caused other problems. I've also tried to "attach process" using the same setting via WinDBG but did not produce anything useful.
Also, I switched from MSVS2015 and WDK10 to MSVS2013 and WDK8.1 because their tutorial files led me to missing header files (warning.h many others), and package files.
Can anyone show me what I did wrong or what I need to do to fix the 80070002 error? Yes, I am new to driver dev.
I am using the new MessageLoop class introduced in pepper-25 so I can run a background thread with blocking ppapi calls for File IO. Up until now I have been running chrome from visual studio with the flags --single-process and --register-pepper-plugins so I can debug my plugin from within visual studio.
Using these flags I found that the call to PPB_GetInterface get_browser for PPB_MESSAGING_INTERFACE was returning null and after some searching I found this issue which states you must run with the flag --ppapi-out-of-process to get MessageLoop support.
With that flag added get_browser does return a valid interface pointer but I can no longer debug my plugin with the visual studio ide as it cannot attach to the child process that my plugin is run from. Is there anyway to tell it to attach to my plug-in process or a way of running from a single process with support for MessageLoop?
Thanks,
James
To get Visual Studio to attach to child processes automatically, you can use the workarounds described at Can Visual Studio be made to debug child processes like WinDBG?.
A different approach is to use the flags --no-sandbox and --ppapi-startup-dialog when you start Chrome. This will cause a message box to appear with the process id when a plugin process is created. You can then connect the Visual Studio debugger to that process using Debug -> Attach to process... -> pick process id. Of course, you could have attached to the process without the Chrome flags and it's not automatic, so this really just gives you certainty that you're attaching to the right process if you have many running at the same time.
A third approach is to use the free Microsoft-provided debugger WinDbg. It is complex and much less user-friendly than the built-in debugger in Visual Studio, but it does have the ability to attach to child processes automatically. Download is available from http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx.
As for MessageLoop it will not be supported for in-process plugins. As the issue you link to mentions, developers should move to out-of-process, even if it adds the inconvenience of not being able to attach the Visual Studio debugger automatically without workarounds.
I am trying to measure the performance of some functions and methods of a console application project in Visual Studio 2010.
I configured the profiling method to instrumentation. The problem is that the performance monitor doesn't work. The message that I get to the output is:
Profiling started.
Instrumenting w:\MyProject\ProfilingTest\Build\Debug\ProfilingTest.exe in place
Info VSP3049: Small functions will be excluded from instrumentation.
Microsoft (R) VSInstr Post-Link Instrumentation 10.0.40219 x64
Copyright (C) Microsoft Corp. All rights reserved.
File to Process:
w:\MyProject\ProfilingTest\Build\Debug\ProfilingTest.exe --> w:\MyProject\ProfilingTest\Build\Debug\ProfilingTest.exe
Original file backed up to w:\MyProject\ProfilingTest\Build\Debug\ProfilingTest.exe.orig
Successfully instrumented file w:\MyProject\ProfilingTest\Build\Debug\ProfilingTest.exe.
The process cannot access the file 'w:\MyProject\ProfilingTest\Build\Debug\ProfilingTest.exe' because it is being used by another process.
Data written to w:\MyProject\ProfilingTest\ProfilingTest110611(17).vsp.
Profiling finished.
File contains no data buffers
File contains no data buffers
Analysis failed
The process cannot access the file 'w:\MyProject\ProfilingTest\Build\Debug\ProfilingTest.exe' because it is being used by another process.
Profiling complete.
I presume that the "root of all evil" is:
The process cannot access the file '...' because it is being used by another process.
Did anybody faced such problems trying to profile native applications developed in Visual Studio 2010 and solve them?
Later add:
If, instead of choosing a project to profile, I am choosing directly the built executable, I succeed to profile, without receiving process blocking, I even received the file analysis. However, the monitoring application is crashing at the end of the profiling. I suspect is related to IDE, but I can't tell for sure.
from the performance wizard choose executable as your target and give the path to the executable. This solved problem for me.
Use process explorer's find handle feature (ctrl + F) to figure out which process has ProfilingTest.exe open. That'll get you to the next step of the troubleshooting process.
Another work-around that I found was to do the following:
1) Launch performance wizard
2) choose your project
3) un-check the box to automatically start your profiling
4) Choose "New Performance Session" and choose your project again (top button on Performance explorer window)
5) Select your performance session from "Targets" and choose "Start Profiling"
I wonder if the nice folks at Redmond have taken notice of this..
Regards.
Creating a WCF Service Library in Visual Studio 2008 on Vista x64 is troublesome when referencing an x86 DLL. A service that calls a 32-bit DLL is required to have a platform target of x86 to run on a 64-bit OS. When you do this, the WcfSvcHost throws a BadImageFormatException when you attempt to debug the service. There is a bug report on MS connect. The workaround I used was to coreflag WcfSvcHost as 32-bit.
Manifest Problem
The main issue I've run in to is this third-party native 32-bit DLL fails to load using certain WCF hosts. I receive the following error when a service operation is invoked that uses the third-party DLL:
System.TypeInitializationException: The type initializer for
'' threw an exception.
.ModuleLoadExceptionHandlerException:
A nested exception occurred after the
primary exception that caused the C++
module to fail to load.
System.BadImageFormatException: The module was expected to contain an
assembly manifest. (Exception from
HRESULT: 0x80131018)
NestedException:
The handle is invalid. (Exception from HRESULT: 0x80070006 (E_HANDLE))
This exception is not raised when WcfSvcHost starts, it's raised when the a service operation is invoked that references the 32-bit DLL. What's very interesting, hosting this same service with the same app.config on a console app has no exceptions and works perfectly:
using (ServiceHost host = new ServiceHost (typeof (MsgBrokerService))) {
host.Open ();
Console.WriteLine ("running");
Console.ReadLine ();
This exception occurs right after:
'WcfSvcHost.exe' (Managed): Loaded
'C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.3053_
none_d08d7bba442a9b36\msvcm80.dll'
Again, the console app does not have an exception and loads the same DLL:
'ConsoleApp.vshost.exe' (Managed):
Loaded
'C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.3053_
none_d08d7bba442a9b36\msvcm80.dll'
See answer from Microsoft Product Support.
Update #1: Both the console application and the WcfSvcHost.exe host process runs under the same session and logged-in user (me). I've copied WcfSvcHost.exe to the directory of the service, manually launched and experienced the same result. I've also checked the Windows Event Log for additional information and used sxstrace, but nothing was logged.
Running Process Explorer, I've verified the following are the same between the two processes:
Image: 32-bit
Current Directory
User/SID
Session
Security (groups denied, privileges disabled)
Running Process Monitor, and configuring symbols, I see WcfSvcHost looks for the following registry and files, while the console host does not. Process Monitor logs a lot of data and I'm not sure what I'm looking for :(.
HKLM\SOFTWARE\Microsoft\Fusion\PublisherPolicy\Default\policy.8.0.msvcm80__b03f5f7f11d50a3a
C:\Windows\assembly\GAC_32\msvcm80\8.0.50727.3053__b03f5f7f11d50a3a
C:\Windows\assembly\GAC_MSIL\msvcm80\8.0.50727.3053__b03f5f7f11d50a3a
C:\Windows\assembly\GAC\msvcm80\8.0.50727.3053__b03f5f7f11d50a3a
Update #2: This same exception occurs when the service is hosted in production on IIS 6 / Windows Server 2003.
Update #3: The 3rd-party 32-bit .NET assembly is the StreamBase API:
sbclient.dll (managed)
monitor.netmodule (managed)
dotnetapi.dll (unmanaged)
pthreads-vc8.dll (unmanaged)
Update #4: Added manifests without success:
Verified that dotnetapi.dll and pthreads-vc8.dll have RT_MANIFEST. The sbclient.dll .NET assembly did not have a manifest
Removed sbclient.dll from the GAC
Registered sbclient.dll for verification skipping
Added a manifest via mt.exe to both sbclient.dll and monitor.netmodule
Verified manifest was added and that the expected files were loaded during testing (via Visual Studio - debug modules window)
The same BadImageFormatException is thrown under BackgroundWorker.OnDoWork(), and the call stack shows a call to dotnetapi.dll...DefaultDomain.Initalize().
I have verified that msvcm80.dll does not have a manifest, I believe this is the only file loaded that doesn't have a manifest :)
Interesting find
When I load monitor.netmodule in Reflector, it says:
'monitor.netmodule' does not contain
an assembly manifest.
Even though it displays an error, Reflector is still able to disassemble the managed code.
a bit late but you can also change the app pool setting "Enable 32-bit Applications" to true in advanced settings.
Microsoft Product Support has resolved this question: It's by design. The unmanaged code is not loaded in the default AppDomain when using WcfSvcHost or the IIS WCF host.
A pure image will use a CLR version of
the C run-time library. However, the
CRT is not verifiable, so you cannot
use the CRT when compiling with
/clr:safe. For more information, see C
Run-Time Libraries.
http://msdn.microsoft.com/en-us/library/k8d11d4s.aspx
I cannot provide an explanation for the error, only my initial suspicion that there is a permission difference between the context in which your code is run as a service and the context in which it is run when you place it in a console application. The E_HANDLE HRESULT is my clue here. Assuming that you run the console application as your logged-in user, you could try configuring the service to start as that user as well. If it works in that configuration, then you can attempt to narrow down what required resource is unavailable when it fails.
I can suggest a workaround. If there is an oddity of the DLL in question that prevents it from working in a hosted service, you can take the sacrificial process approach, so named because it is typically used to isolate a DLL that crashes often. Briefly, you create a proxy program whose only purpose is to load and call the DLL on behalf of your main process, using named pipes or some other IPC method to pass requests and results. If the DLL crashes, you start a new instance of the proxy program. In your case it would have the added benefit that only the wrapper program would need to be 32-bit.
Do you see anything special in the Event viewer?.
In Vista if there a manifest problem you will see traces of it in the Event Viewer, it will tell you to use SxsTrace.
Could you manually add a manifest to this DLL yourself, using the mt.exe file?
MSDN Article on using mt.exe
This may seem a bit dumb; but make sure your service is running in the correct application pool.
Ran into this issue myself. I found a helpful post. As noted in other posts, Microsoft stated this is by design. Basically you need to:
Locate your version of WcfSvcHost.exe. (for me and visual studio
2017: C:\Program Files (x86)\Microsoft Visual
Studio\2017\Professional\Common7\IDE)
Launch developer command prompt
Execute cmd: copy C:\SourcePath\WcfSvcHost.exe
C:\DestinationPath\WcfSvcHost32.exe (Destination doesn't matter)
cmd: corflags /32BIT+ /Force WcfSvcHost32.exe (may need to cd to DestinationPath
In visual studio open the WCF project properties > Debug tab > Start External program: C:\DestinationPath\WcfSvcHost32.exe
Also add your command line arguments:
/service:MyWCFProjectName.dll
/config:MyWCFProjectName.dll.config
Note: You do not need to use ($ProjectDir) here
Launch the app. You are now free to launch WcfServiceHost.exe seperately.
Optionally go to solution > Set Startup Projects > Multiple Startup Projects > Choose the Wcf project and the client project.