‘AutoMapper’ already has a dependency defined for ‘Microsoft.CSharp’


This is how the story begins. On our build server we are using a JetBrains Resharper CLT to generate a code analysis report. In one of the projects build we started getting the following exception log:

Executing the powershell script: C:\install\TFS \1.0.691\resharp.ps1
JetBrains Inspect Code 2016.1.2
Running in 64-bit mode, .NET runtime 4.0.30319.42000 under Microsoft Windows NT 6.2.9200.0
'AutoMapper' already has a dependency defined for 'Microsoft.CSharp'.
--- EXCEPTION #1/2 [InvalidOperationException]
Message = "'AutoMapper' already has a dependency defined for 'Microsoft.CSharp'."
ExceptionPath = Root.InnerException
ClassName = System.InvalidOperationException
HResult = COR_E_INVALIDOPERATION=80131509
Source = NuGet.Core
StackTraceString = "
  at NuGet.Manifest.ValidateDependencySets(IPackageMetadata metadata)
     at NuGet.Manifest.ReadFrom(Stream stream, IPropertyProvider propertyProvider, Boolean validateSchema)
     at NuGet.LocalPackage.ReadManifest(Stream manifestStream)
     at NuGet.OptimizedZipPackage.EnsureManifest()
     at NuGet.SharedPackageRepository.OpenPackage(String path)
     at NuGet.LocalPackageRepository.GetPackage(Func`2 openPackage, String path)
     at NuGet.LocalPackageRepository.<>c__DisplayClass13.<FindPackage>b__f(String path)
     at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
     at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
     at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source)
     at NuGet.LocalPackageRepository.FindPackage(Func`2 openPackage, String packageId, SemanticVersion version)
     at NuGet.SharedPackageRepository.FindPackage(String packageId, SemanticVersion version)
     at JetBrains.ProjectModel.Packages.SharedPackageRepositoryInTemp.FindPackage(String packageId, SemanticVersion version)
     at NuGet.PackageRepositoryExtensions.FindPackage(IPackageRepository repository, String packageId, SemanticVersion version, IPackageConstraintProvider constraintProvider, Boolean allowPrereleaseVersions, Boolean allowUnlisted)
     at NuGet.PackageReferenceRepository.GetPackage(PackageReference reference)
     at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
     at System.Linq.Enumerable.WhereEnumerableIterator`1.MoveNext()
     at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
     at JetBrains.ProjectModel.Packages.NuGetSolutionManager.<>c__DisplayClass7.<GetInstalledPackages>b__6()
     at JetBrains.Util.ILoggerEx.Catch[TValue](ILogger th?s, Func`1 F, ExceptionOrigin origin, LoggingLevel loggingLevel)

Continue reading “‘AutoMapper’ already has a dependency defined for ‘Microsoft.CSharp’”

‘AutoMapper’ already has a dependency defined for ‘Microsoft.CSharp’

Enumerating AppDomains in a remote process


I am working on adding a support for ASP.NET performance counters into Musketeer. Compared to other .NET performance counters they have quite surprising instance names. ASP.NET developers decided that their performance counter instances will be identified by names derived from the AppDomain names (more information can be found here). This is probably due to a fact that one process may host multiple ASP.NET applications, thus one counter instance per process won’t be enough. Consequently, in order to match collected metrics with process ids we need to know which AppDomain belongs to which process. How can we do that?

Continue reading “Enumerating AppDomains in a remote process”

Enumerating AppDomains in a remote process

.natvis files and type templates in WinDbg


When we work with binary data we often use the dt command to group the bytes into meaningful fields, eg.

0:000> dt ntdll!_PEB @$peb
   +0x000 InheritedAddressSpace : 0 ''
   +0x001 ReadImageFileExecOptions : 0 ''
   +0x002 BeingDebugged    : 0x1 ''
   +0x003 BitField         : 0x8 ''
   +0x003 ImageUsesLargePages : 0y0
   +0x003 IsProtectedProcess : 0y0
   +0x003 IsLegacyProcess  : 0y0
   +0x003 IsImageDynamicallyRelocated : 0y1
   +0x003 SkipPatchingUser32Forwarders : 0y0
    ...

The problem arises when the library owner does not provide type information in the symbol files. We are usually left with a manual decomposition of the bytes in a binary editor (010 Editor has a nice template system). Wouldn’t it be great if we had some template system available also in the debugger? I have some good news for you: with the latest release of WinDbg we received a very powerful feature: .natvis files. There were even two Defrag Tools episodes dedicated to this functionality: Defrag Tools #138 and Defrag Tools #139. Let’s first analyze how the .natvis files are built, to later use them in our binary data analysis.

Continue reading “.natvis files and type templates in WinDbg”

.natvis files and type templates in WinDbg

!injectdll – a remote thread approach


In the last post I presented you my first WinDbg extension with a !injectdll command. Theoretically everything was correct, but after some more testing I noticed that the command is not always working as expected. Andrey Bazhan was pretty quick in pointing this out and advised me to use a remote thread, which, as you will see, is a much better approach. But let’s first have a look at the problems in lld 1.0.

Continue reading “!injectdll – a remote thread approach”

!injectdll – a remote thread approach

!injectdll – a WinDbg extension for DLL injection


Today I have a pleasure to present you my first WinDbg extension lld🙂 For now it contains only one command: !injectdll, which allows you to inject a DLL into the process being debugged. There is a similar command in the sdbgext extension, but it works only for 32-bit processes. The usage is extremly simple – just remember to load the extension in the correct bitness (32-bit version for 32-bit processes). Example session may look as follows:

0:000> .load lld
0:000> !injectdll c:\temp\Test.exe
ModLoad: 00000001`3f820000 00000001`3f924000   c:\temp\Test.exe
ModLoad: 000007fe`fd960000 000007fe`fd98e000   C:\Windows\system32\IMM32.DLL
ModLoad: 000007fe`ff410000 000007fe`ff519000   C:\Windows\system32\MSCTF.dll
(bac.5a0): Break instruction exception - code 80000003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x30:
00000000`778c7800 cc              int     3

The binaries can be found under the release tab of the source code repository.

Continue reading “!injectdll – a WinDbg extension for DLL injection”

!injectdll – a WinDbg extension for DLL injection

Diagnostics Kit released!


For some time I have been working on a monitoring solution for developers. Today I have a pleasure to announce its first official release. It is a set of tools which should help you better diagnose your applications. As there are many monitoring solutions on the market you may be using one of them (and that’s great). However, I’ve observed that it’s still uncommon for developers to collect application logs in one place. Therefore OPS monitor IIS logs and developers are checking application-specific targets. This is not the best approach as you can’t see at first sight if something is going wrong with your application. Few years ago I had an idea of an application board which will show statuses of applications on all the servers. This is one of the central part of the Diagnostics Kit and I named it the Diagnostics Castle. A sample board might look as follows:

diaggrid

Continue reading “Diagnostics Kit released!”

Diagnostics Kit released!

Incorrect password in Remote Desktop Connections Manager (with some DPAPI insights)


Few weeks ago my Remote Desktop Connections Manager started to report an access denied while trying to connect to some servers on my list, prompting me for a password. I was pretty sure the password stored in the RDCMan profile was correct, but didn’t really have time to investigate it further. Until today🙂

Continue reading “Incorrect password in Remote Desktop Connections Manager (with some DPAPI insights)”

Incorrect password in Remote Desktop Connections Manager (with some DPAPI insights)