I have a native C++ project that uses COM to communicate with a separate project in VB.NET. I have been able to successfully profile the native project in the past by attaching the project to a separate exe that references the native dll. I'm now trying to profile the native project by connecting to dllhost.exe. This configuration works, since I'm able to debug through dllhost, but if I try and profile the code (or just attach the profiler to dllhost while I'm debugging), the profiler stops and I get the following output:
PRF0010: Launch Aborted - Unable to start vsperfmon.exe
Error VSP1712: Invalid File: C:\...\MyProj110609.vsp
PRF0025: No data was collected.
I know the profiler works since I can get results using a different configuration. I also know the debug configuration works. Any idea on what's going wrong?
After some research, I found that the only way to do it with dllhost was to use the command line profiler. Go to the VS 2010 command prompt, and type in
VSPerfCmd /start:sample /output:c:\TestFile.vsp
VSPerfCmd /attach:[PID]
where c:\TestFile.vsp is the name and path of the output file, and [PID] is the profile ID of dllhost. Run whatever you want to profile, and when you're done, type in
VSPerfCmd /detach:[PID]
VSPerfCmd /shutdown
and you'll have your performance report.
Related
Sorry if this is a duplicate -- I've looked at this and this and others, but I can't find my problem.
A program I build debugs successfully on my local machine, but when I try to debug it remotely, I can't set breakpoints in my code. I've opened the modules window in the debugger, and under Symbol Status for my executable, it tells me "Cannot find or open the PDB file." I try to load it manually, and get the error, "A matching symbol file was not found in this folder."
I created a minimal (hello world) app, and I can debug that, so I'm able to reach the remote PC. Indeed, the app does start up and run on the remote system. So, it isn't an access issue.
Not sure what else to say about this, other than to show you my project debugging configuration:
Any ideas are MOST welcome. Thanks...
Well, I found the answer -- I needed to check the "deploy" box in the Configuration Manager window. This surprised me a little, as using the "deploy" command (available from right-clicking the project property) didn't do the trick. Evidently, there's some behind-the-scenes magic that takes place when the deploy box is checked.
I am trying to get code coverage metrics for an ASP.NET REST service (that uses a global.asax file) running in IIS. I have followed the following basic steps:
Set environment variable using "VSPerfClrEnv /globaltraceon" (then reboot computer) (I have also tried /globalsampleon)
Instrument the DLLs for code coverage using “vsinstr –coverage ” and I do this for the 5 DLLs I am interested in
Start the profiler using "VSPerfCmd /start:coverage /output:cc.coverage /CS /user:Everyone"
Start the service in IIS 10 1703, use Task Manager to note the PID for w3wp.exe
Attach the profiler to the service using "VSPerfCmd /attach:"
Run tests from Visual Studio '17 Enterprise Test Explorer against the service
Use "VSPerfCmd /detach"
Use "VSPerfCmd /shutdown"
But then when I open the cc.coverage file that was created, only one or two of the DLLs (it's not consistent) have coverage results, and the tests absolutely would have exercised code in all 5 DLLs. Am I doing something wrong or missing a step? Thank you!
According to https://blogs.msdn.microsoft.com/tfssetup/2015/08/13/steps-to-check-the-code-coverage-of-a-web-application-via-command-line/, you should issue a iisreset /STOP command before vsperfcmd /shutdown, after vsperfcmd /detach. Not sure if this is the root cause of your problem or not, but it could be considering that it seems like a buffer flush is not occurring faithfully in your scenario. The buffer flush for each module is required in order to get the coverage data out of the session - if all the things aren't properly shutdown, then this can cause buffers to fail to flush their data.
so i have a console application that stitches a pdf into one big long tif however when i go to make a setup project it all seems to work fine until i move the installer to another commutator and run it it installs fine however whenever i run the application it gives an error
The program can't start because ucrtbassed.dll is missing from your computer
i have seen videos where when they add the primary output some msm file is added depending on the library's used in he code however no such file appears when i add my output in the application folder section in the main setup file
edit::
i feel that i cant explain this correctly and thus will upload it as and image this is the main application file inside of the setup project it looks like its only copying the source code when it should also include some dlls
application folder on the setup wizard
You are shipping a debug version of your app, and it is failing because it is asking for the debug version of the Universal CRT (that's why there is a "d" on the end, and it's actually ucrtbased.dll). In general the debug versions of these are available for debugging on developer's machines, not for client machines. So build a release version of your app and see what it does. If it fails looking for ucrtbase.dll, then clients can use this to install it:
https://www.microsoft.com/en-us/download/details.aspx?id=48234
I encountered a hell problem when I attempted to invoke “LoadLibrary” in C# environment. The application was crashed when I pressed “Ctrl + F5” and entered the directly running environment, but it was certainly O.K. if I pressed “F5” entering the debug mode. I tried to directly run the application, it had the same errors. There are some test projects in attach files, I thought that it was enough describing the issue. How did I solve it?
Ps: The solution’s environment must be set to “Debug” and the compile form must be “X64”, then the ConsoleApplication2 project is “Startup project”.
I tried to use the “LibraryEssential” project to invoking the “MathmaticPower” function which was in “MathmaticLibrary” project. But my C# project “ConsoleApplication2” loaded “LibraryEssential” dll file by “PInvoke LoadLibrary”.
Some improvements: I tried to run the C# exe application in "Administrator", It's O.K., but I run it with other user, it's failed! Shall I must run the application in administrator role? I don't want to do so. Have any other ways for the issue?
attach files: LoadLibrary.zip
I am working on an application that installs a system wide keyboard
hook. I do not want to install this hook when I am running a debug
build from inside the visual studio (or else it would hang the studio
and eventually the system), and I can avoid this by checking if the
DEBUG symbol is defined.
However, when I debug the release version of the application, is
there a way to detect that it has been started from inside visual
studio to avoid the same problem? It is very annoying to have to
restart the studio/the computer, just because I had been working on
the release build, and want to fix some bugs using the debugger having
forgotten to switch back to the debug build.
Currently I use something like this to check for this scenario:
System.Diagnostics.Process currentProcess = System.Diagnostics.Process.GetCurrentProcess();
string moduleName = currentProcess.MainModule.ModuleName;
bool launchedFromStudio = moduleName.Contains(".vshost");
I would call this the "brute force way", which works in my setting, but I would like to know whether there's another (better) way of detecting this scenario.
Try: System.Diagnostics.Debugger.IsAttached
For those working with Windows API, there's a function which allows you to see if any debugger is present using:
if( IsDebuggerPresent() )
{
...
}
Reference: http://msdn.microsoft.com/en-us/library/ms680345.aspx
Testing whether or not the module name of the current process contains the string ".vshost" is the best way I have found to determine whether or not the application is running from within the VS IDE.
Using the System.Diagnostics.Debugger.IsAttached property is also okay but it does not allow you to distinguish if you are running the EXE through the VS IDE's Run command or if you are running the debug build directly (e.g. using Windows Explorer or a Shortcut) and then attaching to it using the VS IDE.
You see I once encountered a problem with a (COM related) Data Execution Prevention error that required me to run a Post Build Event that would execute editbin.exe with the /NXCOMPAT:NO parameter on the VS generated EXE.
For some reason the EXE was not modified if you just hit F5 and run the program and therefore AccessViolationExceptions would occur on DEP-violating code if run from within the VS IDE - which made it extremely difficult to debug. However, I found that if I run the generated EXE via a short cut and then attached the VS IDE debugger I could then test my code without AccessViolationExceptions occurring.
So now I have created a function which uses the "vshost" method that I can use to warn about, or block, certain code from running if I am just doing my daily programming grind from within the VS IDE.
This prevents those nasty AccessViolationExceptions from being raised and thereby fatally crashing the my application if I inadvertently attempt to run something that I know will cause me grief.