I've noticed that when Visual Studio 2012 loads/initializes projects (when opening a solution or when changing platforms/configurations), it may execute some MSBuild targets - those that are listed as InitialTargets (it doesn't always do that - sometimes it waits until you actually build it; I can't figure out when exactly, but that's a different question).
Anyway, these targets may generate some output in the form of MSBuild messages. If the targets were being run as part of a build, these messages would go to the output window of Visual Studio (and perhaps a log file). These "load-time targets", though, do not seem to send their output to the output window.
How can I see or log the output of MSBuild targets which execute outside of build time, and specifically in initialization time?
The best information source from the MSBuild team at Microsoft I could find is dated (2005), but may still be actual if no one could come up with fresher information:
The project load logger is used when projects are opened. It discards all messages logged while the project is opened, puts warnings in the error list, and displays any errors in a message box to the user. The errors displayed are quite detailed and useful in helping diagnose project file formatting issues.
Related
After failing to get DebugDiag to analyse crash-dump files it was suggested that I try using WinDbg instead.
The crash-dump files have been created on a Windows Server 2016 box, running my ASP.Net 4.5.2 web application on IIS-10. My ASP.Net web application contains several 3rd party components, with their individual DLLs.
I have copied the crash-dump files onto my Windows 10 development machine, and am running WinDbg locally instead of on the server.
The problem is... when I run !analyze -v in WinDbg on any of the crash-dump files, it effectively hangs while "Downloading file xxx.DLL" (xxx.DLL being the name of just one of the 3rd party component DLLs), and eventually cancels itself after a period of time.
I'm running WinDbg on the same machine that I built the website on in the first place... so is there a way of telling WinDbg that it can find the DLL in a particular location on the local machine?
I obviously don't have a .pdb file for any of the 3rd party components, and so I'm not bothered about it loading symbols for those DLLs... but either I somehow tell it to ignore those particular DLLs, or I tell it how to find them locally.
Can anybody point me in the right direction?
You don't have to analyze the dump file with !analyze -v.
If you need to load dll, then .load D:.... is enough.
To maunal analyze a dump file.
Please run .loadb sos clr to load debug module. If the crash server and your machine run different version of .net framework. Then you need to load sos.dll manually.
When you need to debug .net application in IIS, !mex extension is recommened.
https://www.microsoft.com/en-us/download/details.aspx?id=53304
You can load mex.dll via .load c:\.....\mex.dll
!mex.aspxpages can show all requests inside the process and their process
!mex.mthreads show the status of all threads
!mex.clrstack2 will show all exceptions and mananaged call stack in specific thread.
1.You can use ~* k to load the full call stack in all threads and !mex.mthreads check status.
Then you may find something like KERNELBASE!RaiseException in specific thread
2.Then go to this thread via threadid~ like 12~
3.Run !mex.clrstack2 and it will show the crash exception
Basically, no, you cannot speed up the process of loading symbols for DLLs where you don't have symbols. IMHO, the only way of speeding up the symbol process would be to disable the HTTP server, so that symbols are only searched on your local disk.
See also: How to set up symbols in WinDbg if you have not done this often.
Getting a HTTP 404 for those files should not take very long. However, it tries various file endings and pointers etc. Sometimes Microsoft servers are slow. Also, having a lot of 3rd party DLLs may sum up of course. That can be pretty anoying.
I'll start by saying I don't 100% understand everything I had to do, but here are the step I took to discover where the stackoverflow issue was in my application...
The majority of the information came from this blog.
On the server I added the following registry settings to create the crash dump files...
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\w3wp.exe]
"DumpCount"=dword:00000005
"DumpFolder"=hex(2):43,00,3a,00,5c,00,43,00,72,00,61,00,73,00,68,00,44,00,75,\
00,6d,00,70,00,73,00,5c,00,00,00
(The DumpCount is the number of files to store before it starts overwriting old ones - DumpFolder is where the files are to be saved, is a REG_EXPAND_SZ and in my case represents C:\CrashDumps\)
Waited for crashes to happen
Copied the crash files into a directory on my local machine called C:\WinDbg\CrashDumps\
Create another directory called C:\WinDbg\Symbols, into which I placed...
clr.dll (from the server, taken from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\)
sos.dll (from the server, taken from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\)
all .dll and .pdb files from my local development environment, including third party component .dll files
Installed WinDbg via Windows Store on my Windows 10 development machine
Ran windbgx -y c:\windbg\symbols via Run command (for some reason it's windbgx on my machine but maybe that's because it's via the Store rather than manual download)
In the file menu Open dump file and select one of the dump files in C:\WinDbg\CrashDumps
Ran the following commands...
.symfix
.reload
.load c:\windbg\symbols\sos.dll (see note 1 below)
!clrstack (see note 2 below)
Although this didn't give me all the information I expected, what it did show was that one of my 3rd party components was 100% to blame for the stackoverflow exception.
Note 1 - Lots of places I read said that .loadby sos clr should be used, but that just gave me The call to LoadLibrary(C:\ProgramData\Dbg\sym\clr.dll\5E7D1F3B9eb000\sos.dll) failed and I couldn't figure out how to fix it... so instead I've used .load c:\windbg\symbols\sos.dll.
Note 2 - The !clrstack command worked because WinDbg appeared to pre-select the thread that had the exception. The other option is to use ~*e !clrstack which will show you call stacks for ALL threads.
Okay, so this problem is kinda complicated, but I'll try to make it as simple as possible.
So I have this Bot Service created in Microsoft's Azure platform. It's been hooked up to BitBucket with the continuous integration option. Then, I tried following the instructions here in order to be able to debug the bot locally with Visual Studio. I downloaded and installed all the requisite tools and pulled the BitBucket project into a local repository. However, when I tried running 'dotnet restore' in the messages folder, I received this error message:
C:\...\messages\project.json(1,1): error MSB4025: The project file could not be loaded. Data at the root level is invalid. Line 1, position 1.
This project.json file was automatically built by Azure; why should it be invalid? The contents look like this:
{
"frameworks": {
"net46":{
"dependencies": {
"Microsoft.Bot.Builder.Azure": "3.1"
}
}
}
}
I've also tried the same thing with Visual Studio 2017, this time including the messages.csproj file in the messages folder. And this time, dotnet restore said I needed to specify a project/solution file because there multiple in the folder. I dunno if that's necessarily a problem, but it's not mentioned at all in the official guide, so it's at least a bit suspicious. Anyway, specifying project.json leads to the same error, while specifying messages.csproj seems to work all right and outputs this:
NuGet Config files used:
C:\Users\Connor.Johnson\AppData\Roaming\NuGet\NuGet.Config
C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config
Feeds used:
https://api.nuget.org/v3/index.json
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\
That being the case, I run debughost.cmd. Previously, I had to manually copy over project.lock.json from the downloadable zip file available on Azure (it's in gitignore) as the debughost thing wouldn't automatically restore that stuff. More recently that doesn't seem to be a problem any more. Anyway, the debughost.cmd stuff works fine.
Naw, the real problem's when I try to open this stuff in Visual Studio. See, when I try to open the bot.sln file, I get this error message:
One or more projects in the solution were not loaded correctly. Please see the Output Window for more details.
Okay, so the Output Window gives me this super useful information:
Some of the properties associated with the solution could not be read.
Uh huh... Well, in terms of what shows up in Visual Studio, only debughost.cmd, commands.json, and readme.md show up. The messages folder is there, but it's empty. There's also an Azure Functions func thing. That's it.
Now I've looked all over for information on this issue, but I'm apparently the only person who's had it. Moreover, I've tried opening the Bot in VS2015, VS2017, from only the source code downloaded from Azure (i.e., without the Git stuff), and from the BitBucket repository. I've also tried using connecting to source control from the Team Explorer in Visual Studio. Nothing's working! I can't find any information on what might be incorrectly configured, and I find it odd that I should have to change anything. I could serrrrrrriously use some help here.
When running a UWP project I'm working on I receive the following dialog.
"Unable to activate Windows Store app 'MyAppsMangledName'. The 'MyExeName' process started, but the activation request failed with error 'The App didn't start'."
The Visual Studio output has the following.
The thread 0x3d4c has exited with code -1073741515 (0xc0000135).
The thread 0x3b50 has exited with code -1073741515 (0xc0000135).
The program 'MyExeName' has exited with code -1073741515 (0xc0000135) 'A dependent dll was not found'.
The Event Viewer has 3 events that basically restate the popup dialog in 3 different ways and nothing else.
Running Process Monitor during the startup shows me many dlls being successfully loaded but nothing indicating failure besides some NAMENOTFOUND events which unfortunately don't show what name wasn't found.
In Win32 a helpful dialog usually indicates which dll could not be loaded. And of course with .Net apps the fusion logs make tracing this very straight forward. But for Store/UWP apps I can't seem to find a good way to track down the offending dependency.
This just hit me too on a project I'm working on. And after much digging, someone on my team was able to figure it out. So figured I'd share it for others struggling with the same issue.
We're doing UWP with C++ using VS2015. So with that in mind, there is a program called gflags located for me at C:\program Files (x86)\Windows Kits 10\Debuggers\x64\gflags.exe
So you'll want a cmd window with admin, and run the command gflags.exe -i your-program-name.exe +sls
Note: gflags wasn't in my path so either add the path or navigate to where it is before executing the command.
Just pass in the name of the exe without directories. What it does is sets a registry setting for VS that turns on sls (show loader snaps) for exe's matching that name. Then run your application in VS and and you'll get a large amount of dll loading information including names of the dlls that fail to load in your output window. In our case it was this:
5038:34f4 # 789320468 - LdrpProcessWork - ERROR: Unable to load DLL: "vccorlib140d_app.DLL", Parent Module: "E:\projects---\Source\Builds\vs2015_Debug_UWP_x64\AppX---.exe", Status: 0xc0000135
Another quicker alternative way to test this (YMMV) was to compare the output with another build config that does work. In our case, we can run release builds just fine, but debug builds barf. And the release output showed vccorlib140_app.dll loaded while the debug had it missing.
When I try to run codecoverage tool on release bits of my website I get an empty .coverage file containing the following error:
Empty results generated: No binaries were instrumented. Make sure the tests ran, required binaries were loaded, had matching symbol files, and were not excluded through custom settings. For more information see http://go.microsoft.com/fwlink/?LinkID=253731
This issue does not occur if I run it on the debug version of the same build.
These are the exact steps I perform:
- start monitoring code coverage on IIS server
codecoverage collect /IIS /session:test /output:test.coverage
- perform a few click around the website
- stop monitoring code coverage
codecoverage shutdown /session:test
Note! I do hae the .pdb files in the same place as the binaries.
Any ideas?
Thanks,
Cristina
I finally managed to get to the bottom of this. For the release build, there were 2 things I needed to change in the .config file
specify the path to the Symbols (apparently this is needed even if the .pdf files are in the same location as the dlls)
I had to remove the default exclusion list since these included Microsoft public key tokens and our product is a Microsoft product.
Hope this will be helpful for others running into the same situation.
Regards,
Cristina
Try this: Enabling Profiling.
[UPDATE 5 Jun 2013 14:04:00-04:00 UTC]
I also found this article that you may be interested in: Application Analytics: What Every Developer Should Know.
As far as Code Coverage is concerned, I didn't see anything specific to using the VS Code Coverage tool and configuring for IIS. I did see lots of articles about testing web applications in general, some of which involved setting up code coverage (Setting Up Machines and Collecting Diagnostic Information Using Test Settings being an example).
Sorry I couldn't be of more help to you.
I have the following build target set to do my deploys, as mentioned by Hanselman in his Tiny Happy Features #3 and as also noted in many other places as what I consider to be the recommended approach:
msbuild my_web_application.csproj /p:Configuration=Production;
DeployOnBuild=true;
PublishProfile=Production;
VisualStudioVersion=11.0;
AllowUntrustedCertificate=true;
AuthType=NTLM
This does the job, and replaces the deployment step I previously had via invoking ms deploy on the command line:
msdeploy.exe" -source:package="c:\source_to_my_web_application.zip" -dest:auto,my_server_name,includeAcls="False" -verb:sync -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -setParamFile:"c:\source_to_my_web_application\Package.SetParameters.xml"
The biggest difference I can see in the two methods is that the command line call will only push over the files that have modifications, whereas the msbuild call sends over the entire web application every time.
Is there a way to make the msbuild version do the "sync" behavior, like the direct call to msdeploy did for me?
From what I've been able to establish, syncing from a package (like the one created for this particular MSBuild command) will find differences related to the local working copy it's trying to deploy from.
If I do a fresh checkout, then build and deploy, it'll publish the entire web application.
If I do a clean and rebuild on that working copy, it'll only publish the dlls that got rebuilt.
If I do a build on that, it'll only publish the web.config files that got transformed and some other random dlls that I can't make rhyme or reason out of.
The bottom line, I guess, is that with our CI server setup, it should be assumed that all files will be published to the server, and if it happens to publish fewer than that, it's a bandwidth bonus.
As a side note, I've also encountered random, unreliable 404 errors while doing otherwise normal ms deploy commands. They seem to be intermittent, and can vary between my own workstation, my colleagues, and the CI server so that the MS Deploy service will return a 404 or execute just fine within seconds of each successive call. Solutions I've found for this type of behavior range from restarting Visual Studio to uninstalling and reinstalling various components, and making sure you do it in the right order and only the second Tuesday of the third week of any month ending in "ary"...
The takeaway for me is that this tool is sketchy, and that if you can get a setup to work with any amount of reliability it's a miracle and you should not touch it ever again and pray to the silicon gods that it stays that way.