Category Archives: Development

WinDbg: SOSEX Help – Command Reference

SOSEX je jedno z mála rozšíření Windows Debuggeru pro .NET (managed code). Přidává pár užitečných příkazů k základnímu SOS, není však snadné seznam podporovaných příkazů online najít.
Seznam příkazů se dá získat přes !sosex.help. Výstup se může hodit, pokud hledáte, která extension bude pro váš scénář diagnostiky nejpříhodnější.

0:000> !sosex.help
SOSEX - Copyright 2007-2015 by Steve Johnson - http://www.stevestechspot.com/
To report bugs or offer feedback about SOSEX, please email sjjohnson@pobox.com
Quick Ref:
--------------------------------------------------
bhi       [filename]                                     BuildHeapIndex - Builds an index file for heap objects.
bpsc      (Deprecated.  Use !mbp instead)
chi                                                      ClearHeapIndex - Frees all resources used by the heap index and removes it from memory.
dlk       [-d]                                           Displays deadlocks between SyncBlocks and/or ReaderWriterLocks
dumpfd    <FieldAddr>                                    Dumps the properties of a FieldDef structure
dumpgen   <GenNum> [-free] [-stat] [-type <TYPE_NAME>]   Dumps the contents of the specified generation
                   [-nostrings] [-live] [-dead] [-short]
finq      [GenNum] [-stat]                               Displays objects in the finalization queue
frq       [-stat]                                        Displays objects in the Freachable queue
gcgen     <ObjectAddr>                                   Displays the GC generation of the specified object
gch       [HandleType]... [-stat]                        Lists all GCHandles, optionally filtered by specified handle types
help      [CommandName]                                  Display this screen or details about the specified command
lhi       [filename]                                     LoadHeapIndex - load the heap index into memory.
mbc       <SOSEX breakpoint ID | *>                      Clears the specified or all managed breakpoints
mbd       <SOSEX breakpoint ID | *>                      Disables the specified or all managed breakpoints
mbe       <SOSEX breakpoint ID | *>                      Enables the specified or all managed breakpoints
mbl       [SOSEX breakpoint ID]                          Prints the specified or all managed breakpoints
mbm       <Type/MethodFilter> [ILOffset] [Options]       Sets a managed breakpoint on methods matching the specified filter
mbp       <SourceFile> <nLineNum> [ColNum] [Options]     Sets a managed breakpoint at the specified source code location
mdso      [Options]                                      Dumps object references on the stack and in CPU registers in the current context
mdt       [TypeName | VarName | MT] [ADDR] [Options]     Displays the fields of an object or type, optionally recursively
mdv       [nFrameNum]                                    Displays arguments and locals for a managed frame
mfrag     [-stat] [-mt:<MT>]                             Reports free blocks, the type of object following the free block, and fragmentation statistics
mframe    [nFrameNum]                                    Displays or sets the current managed frame for the !mdt and !mdv commands
mgu       // TODO: Document
mk        [FrameCount] [-l] [-p] [-a]                    Prints a stack trace of managed and unmanaged frames
mln       [expression]                                   Displays the type of managed data located at the specified address or the current instruction pointer
mlocks    [-d]                                           Lists all managed lock objects and CriticalSections and their owning threads
mroot     <ObjectAddr> [-all]                            Displays GC roots for the specified object
mt        (no parameters)                                Steps into the managed method at the current position
mu        [address] [-s] [-il] [-n]                      Displays a disassembly around the current instruction with interleaved source, IL and asm code
muf       [MD Address | Code Address] [-s] [-il] [-n]    Displays a disassembly with interleaved source, IL and asm code
mwaits    [-d | LockAddr]                                Lists all waiting threads and, if known, the locks they are waiting on
mx        <Filter String>                                Displays managed type/field/method names matching the specified filter string
rcw       [Object or SyncBlock Addr]                     Displays Runtime Callable Wrapper (RCW) COM interop data.
refs      <ObjectAddr> [-target|-source]                 Displays all references from and to the specified object
rwlock    [ObjectAddr | -d]                              Displays all RWLocks or, if provided a RWLock address, details of the specified lock
sosexhelp [CommandName]                                  Display this screen or details about the specified command
strings   [ModuleAddress] [Options]                      Search the managed heap or a module for strings matching the specified criteria

ListGcHandles - See gch

Use !help <command> or !sosexhelp <command> for more details about each command.
You can also use the /? (or -?) option on any command to get help for that command.

AppService: Nastavení časové zóny pomocí WEBSITE_TIME_ZONE App Setting (a mnoho dalších)

Ve výchozím stavu běží AppServices v UTC. Existuje však téměř nedokumentovaná možnost (nebo minimálně velmi málo známá), kterak časovou zónu aplikace změnit. Stačí přidat konkrétní nastavení mezi Application Settings vaší aplikace (v Azure Portalu) a KUDU se o správný čas postará. Dá se takto nastavit mnoho věcí:

  • WEBSITE_TIME_ZONE, např. Central Europe Standard Time (seznam podporovaných hodnot)
  • SCM_TOUCH_WEBCONFIG_AFTER_DEPLOYMENT = 1/0 – dělá, co říká (default je 1)
  • SCM_TRACE_LEVEL = 1..4 – v rozsahu od 1 do 4 můžete navýšit míru podrobností pro tracing  (default je 1 – nejnižší)
  • Volby pro Build/GIT
  • Volby pro ukládání site na disk a cachování
  • Nastavení verze Node/NPN
  • WEBSITE_LOAD_CERTIFICATES – načtení certifikátů
  • Nízkoúrovňové diagnostické přepínače
  • WEBSITE_DISABLE_SCM_SEPARATION – zajímavě vypadající volba, která vám umožní hostovat vaší aplikaci a SCM (Kudu) ve stejném sandboxu (a potenciálně tak ušetřit zdroje, zejména paměť) – bohužel je tato volba označena jako legacy-obsolete a unsupported (podle všeho funguje, ale ruku do ohně už za to nedávají)
  • …a mnoho dalších

Úplný seznam parametrů najdete v Project KUDU Wiki..

Mockování ConfigurationSection (nebo celého configu)

Při unit-testování se někdy ocitnete v situaci, kdy potřebujete namockovat ConfigurationSection, resp. svého potomka. Konfigurace jsou v .NET ale celkem zapouzdřené a není úplně jednoduché překonat jejich výchozí read-only pojetí.

Nejlepší by samozřejmě bylo se od frameworkovin abstrahovat a na konfigurační data přistupovat přes nějaký adaptér, někdy ale prostě nemůžete být 100% pure (třeba musíte ConfigSection někomu dál předat), a přesto chcete nějaké pokrytí testy.

Existuje obskurní, nicméně funkční, cest, jak ConfigurationSection namockovat (případně celý konfigurační soubor, pokud je potřeba):

1. Vytvořte fake konfigurační soubor(y) ve svém testovacím projektu

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
	<configSections>
<section name="mySection" type="MyConfigurationSection, MyAssembly" />
	</configSections>
	<mySection>
		<identities>
			<identity clientId="fake_id" name="FAKE_NAME" partitionName="FAKE_PARTITION" permissions="Full" />
		</identities>
	</mySection>
</configuration>

Soubor může být v jakékoliv složce, nejspíš přímo vedle třídy unit-testů.

2. Nastavte, aby se .config kopíroval do výstupu buildu

V Properties souboru nastavte:

  • Build Action = Content
  • Copy to Output Directory = Copy always

3. Vytvořte unit-test, který tento .config souboru použije pro vytoužený fake

[TestClass]
public class MyServiceTests
{
	public TestContext TestContext { get; set; }

	[TestMethod]
	[DeploymentItem("PathInTestProject\\MyServiceTests_ScenarioName.config")]
	public void MyService_DoSomething_ScenarioName_ExpectedBehavior()
	{
		// arrange
		ExeConfigurationFileMap configFileMap = new ExeConfigurationFileMap()
		{
			ExeConfigFilename = Path.Combine(TestContext.DeploymentDirectory, "MyServiceTests_ScenarioName.config")
		};
		Configuration config = ConfigurationManager.OpenMappedExeConfiguration(configFileMap, ConfigurationUserLevel.None);
		MyConfiguarionSection mySection = config.GetSection("mySection") as MyConfiguarionSection ;

		var sut = new MyService(mySection);

		// act
		...
	}
}

V čem to spočívá:

  • Metoda ConfigurationManager.OpenMappedExeConfiguration() vás nechá načíst konfiguraci z libovolného souboru.
  • Atribut [DeploymentItem(...)] zařídí zkopírování souboru z výstupní složky buildu do „test deployment directory“ (např. $(SolutionDir)\TestResults\Deploy_username 2017-09-29 22_02_39\Out\)
  • Přes TestContext.DeploymentDirectory se dostanete na aktuální cestu složky, přičemž do TestContext property se vám automaticky nainjectuje testovací kontext.

Azure: Ověření existence blobu, pokud mám jeho URI

Pokud máte pouze storage account (CloudBlobClient) a URI blobu v něm, není úplně jednoduché existenci blobu ověřit. Přesněji řečeno při touze použít obvyklou metodu ​​ICloudBlob.Exists()​, musíte mít na daný blob referenci. Pro její získání z URI je tu metoda CloudBlobClient.GetBlobReferenceFromServer(Uri blobUri), která však při svém zavolání dělá HEAD request na blob a snaží se dotáhnout jeho metadata. Pokud blob neexistuje, vyhodí už tato metoda výjimku a na nějaké Exists() se už ani nedostane.

Výjimku lze zachytit s pěkným pattern-matchingem:

ICloudBlob blob;
try
{
    blob = blobClient.GetBlobReferenceFromServer(new Uri(url));
}
catch (Microsoft.WindowsAzure.Storage.StorageException ex)
            when ((ex.InnerException is System.Net.WebException wex)
                    && (wex.Response is System.Net.HttpWebResponse httpWebResponse)
                    && (httpWebResponse.StatusCode == System.Net.HttpStatusCode.NotFound))
{
    // blob does not exist, do whatever you need here
    return null;
}
// further code able to use the blob-reference

Pokud s referencí na blob nepotřebujete dále pracovat, tak samozřejmě můžete jeho existenci ověřit vlastním jednoduchým HTTP HEAD requestem z libovolného HTTP klienta.
Každopádně je zde obskurní už to, že máte na daný blob pouze plné URL. Za příčetných okolností byste měli mít k dispozici strukturovanou informaci o názvu containeru a blobu v něm, což by šlo samozřejmě z URL i vyparsovat.

Visual Studio: Klávesové zkratky pro navigaci na další/předchozí metodu v kódu

V Resharperu jsou známé klávesové zkratky pro navigaci na dalšího (Alt+Down) resp. předchozího (Alt+Up) membera v kódu. Málo se ale ví, že i čisté Visual Studio toto nyní umí.

Ve Visual Studiu (minimálně ve verzi 2017, ale nejspíš to umí i starší verze) můžete tyto klávesové zkratky získat namapováním příkazů Edit.NextMethodEdit.PreviousMethod (přestože mluvíme o metodách, ve skutečnosti se skáče po memberech). Tyto commandy bývaly funkční pouze pro Visual Basic, jak se teď ale vývoj pro všechny jazyky sjednocuje, fungují i v C#:

2017-09-26_10-12-19

…já asi zvolím klávesové zkratky Ctrl+UpCtrl+Down, protože mi to nějak lépe jde pod ruce a to výchozí skrolování, co tam je, je stejně k ničemu. Mimochodem Alt+Up/Down používám pro posun řádku/selection o řádek výš/níž.

Azure App Service: Získání full memory dumpu při výskytu určité výjimky

Opakovaně si libuji, co všechno je na Azure App Service z hlediska diagnostiky a správy možné ve srovnání s tradičním webhostingem. Například získat full memory dump je snadné, díky Kudu a SysInternals, které jsou na AppService k dispozici.

…no a pokud ladím konkrétní problém a potřebuji memory dump v momentu výskytu určité výjimky, je to už jenom o správném použití ProcDump ze SysInternals (spustit z Debug Console, kde si aktuální adresář přepnete třeba na LogFiles:


d:\devtools\sysinternals\procdump -accepteula -ma -e 1 -f "FaultException" 9736

…poslední číslo je číslo procesu (získáte z Kudu z Process Exploreru nebo z portálu), v uvozovkách stačí libovolná část názvu typu výjimky (testuje se přes Contains).

Celá věc pak může vypadat třeba takhle:


Kudu Remote Execution Console
Type 'exit' then hit 'enter' to get a new CMD process.
Type 'cls' to clear the console

Microsoft Windows [Version 6.2.9200]
(c) 2012 Microsoft Corporation. All rights reserved.

D:\home>
D:\home\LogFiles>d:\devtools\sysinternals\procdump -accepteula -ma -e 1 -f "FaultException" 9736

ProcDump v9.0 - Sysinternals process dump utility
Copyright (C) 2009-2017 Mark Russinovich and Andrew Richards
Sysinternals - www.sysinternals.com

Process: w3wp.exe (9736)
Process image: D:\Windows\SysWOW64\inetsrv\w3wp.exe
CPU threshold: n/a
Performance counter: n/a
Commit threshold: n/a
Threshold seconds: n/a
Hung window check: Disabled
Log debug strings: Disabled
Exception monitor: First Chance+Unhandled
Exception filter: [Includes]
*FaultException*
[Excludes]
Terminate monitor: Disabled
Cloning type: Disabled
Concurrent limit: n/a
Avoid outage: n/a
Number of dumps: 1
Dump folder: D:\home\LogFiles\
Dump filename/mask: PROCESSNAME_YYMMDD_HHMMSS
Queue to WER: Disabled
Kill after dump: Disabled

Press Ctrl-C to end monitoring without terminating the process.

CLR Version: v4.0.30319

[07:57:32] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:57:40] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:57:50] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:57:55] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:58:02] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:58:10] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:58:20] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:58:24] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:58:32] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:58:40] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:58:50] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:58:55] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:59:02] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:59:10] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:59:20] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:59:25] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:59:32] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:59:40] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:59:50] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:59:55] Exception: E0434F4D.System.Threading.ThreadAbortException ("Thread was being aborted.")
[07:59:59] Exception: E0434F4D.System.ServiceModel.FaultException ("The message with Action '' cannot be processed at the receive
r, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Acti
ons between sender and receiver) or a binding/security mismatch between the sender and the receiver. Check that sender and recei
ver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).")
[07:59:59] Dump 1 initiated: D:\home\LogFiles\w3wp.exe_170829_075959.dmp
[08:00:04] Dump 1 writing: Estimated dump file size is 290 MB.
[08:00:11] Dump 1 complete: 290 MB written in 12.1 seconds
[08:00:12] Dump count reached.

D:\home\LogFiles>

WCF: The message with Action “ cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher.

Pokud voláte WCF webovou službu (SOAP) a dostáváte tuto response

The message with Action “ cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver. Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).

…může to být kromě obvyklých zřejmých důvodů způsobeno i zcela chybějící HTTP-hlavičkou SOAPAction v příchozím HTTP-POST SOAP requestu (match je potom možný pouze na *-wildcard-action, cokoliv jiného končí chybou výše).