https://msdn.microsoft.com/magazine/msdn-magazine-issues

But : mettre en oeuvre les traces dans explorer.exe
Mais avant cela, faire un apprentissage.
Le mécanisme de trace me parait identique dans explorer.exe et dans termsrv.dll.
J'ai depuis longtemps envie de comprendre comment mettre en oeuvre windbg dans un service.
Donc pour commencer :
	tenter de mettre en oeuvre Windbg pour activer les traces dans termsrv.

1 - comment tracer l'activité d'un service ? 
	Divers sites donne une solution :
		- combiner les mécanismes "IFEO" et "Remote Debugging" (néanmoins utilisé sur une seule machine)

	a - activer windbg lors du lancement du prg (ou du service sous certaines conditions)
	Modifier la ruche software ou utiliser gFlags.exe ( et gflgsui.dll de windbg )
	Cas "modification de la ruche software"
	HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
		créer une clé pour le nom du programme à debugger : notepad.exe par exemple
		dans cette clé, créer une chaîne : "Debugger" = chemin de windbg avec des paramètres si besoin
		par exemple :
			"Debugger" = "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe"
	Lors du prochain lancement de "notepad.exe", windbg va prendre la main.

	b - pour termservice : il faut isoler le programme pour ne pas avoir de multiples déclenchements intempestifs
		il faut recopier svchost.exe en MySvchost.exe par exemple et modifier la clé du service "ImagePath"
		A vérifier : la version v1709 modifie le lancement des services qui deviennent presque tous "isolés" (type != 100h)

	c - pour un service : quelques précautions 
		- augmenter la temporisation initiale de 30s par défaut et commune à tous les services !
			HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
				ServicesPipeTimeout Dword 300000 (en décimal, 5 minutes)
			"services.exe" dialogue avec l'exe et attend une réponse pendant "ServicesPipeTimeout" secondes avant de considérer que le démarrage du service a échoué.

		- Windbg utilise le contexte du service qui ne peut pas, par défaut, afficher sur le bureau.
			Donc modifier le paramètre du service  "Allow the service to interact with desktop"
			Cela implique aussi d'utiliser le compte "system".
			Modification faite avec services.msc donc prise en compte sans avoir besoin de redémarrer

https://msdn.microsoft.com/en-us/library/windows/desktop/ms682546%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396 
"The service must be an interactive service, or else the debugger cannot run on the default desktop. 
Note that this technique is no longer supported as of Windows Vista because all services are run in session 
that is reserved exclusively for services and does not support displaying a user interface."

	d - Nécessité de "remote debugging"
		on pourrait maintenant démarrer le service avec "net start termservice" mais ... ca ne marche pas !
		windbg est bien lancé ( vu avec taskmgr ) mais pas d'affichage. 
		Je crois me souvenir que w10 64 bits (ou avant) a introduit une modification au sujet du mode interactif des services. Mais laquelle ?
		
	Ces sites proposent une solution avec une session de "remote debugging" :
	https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/remode-debugging-using-windbg
	https://bugslasher.net/2010/10/14/how-to-debug-a-windows-service/
	http://www.debuginfo.com/articles/debugstartup.html

	e - mise en oeuvre de "remote debugging" 
	NTSD.exe (windbg pour moi) comme debugger attaché au service et windbg qui pilote à distance NTSD.
	Je remplace NTSD par windbg : donc 2 instances de winbdbg dans la même machine.

	https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/remode-debugging-using-windbg
	les flags pour activer certaines fonctionnalités de debuggage
	https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/gflags-commands
	une présensation simple
	https://bugslasher.net/2010/10/14/how-to-debug-a-windows-service/
	http://urosv.blogspot.fr/2010/05/remote-debugging-with-windbg-and-ntsd.html

	Un résumé de l'idée basée sur la combinaison "IFEO" et "remote debugging" (mais en local) : 
		Le système chargera en mémoire le programme à débugger sans le lancer.
 		Il lancera ensuite le debugger NTSD ( windbg pour moi ) : pas d'affichage.
		La ligne de commande de NTSD lui indique de s'attacher au programme à debugger et de communiquer avec un autre debugger.
		Mais l'affichage est impossible avec un service. Il faut donc un second débugger pour dialoguer avec NTSD
		On lance alors WinDbg qui, via le réseau ( le plus simple ), récupère les informations à afficher
		Dans l'autre sens, les saisies faites dans WinDbg sont envoyée à NTSD
		On peut un premier essai en mettant en oeuvre ce mécanisme avec "notepad" comme cible

	La mise en oeuvre dans winpe avec le service "termservice"
		A faire dans la ruche system de winpe ***avant*** de démarrer winpe 
			Modification de la temporisation d'attente du démarrage d'un service 
			Modification du type de démarrage du service termservice afin de la désactiver : "start= disabled"
		Démarrage de winpe
		Modification des clés "IFEO" pour activer le déclenchement du debugger
		Recopie de svchost.exe par exemple en MySvchost.exe ( seule utilité : le retouver plus rapidement dans la liste des tâches)
		Modification de "imagepath" du service pour lancer MySvchost.exe
		Démarrage du parefeu ( est ce bien obligatoire ? )
		Activation le service Termservice "start= demand"
		Démarrage de Termservice
		Lancement de windbg avec la bonne ligne de commande
	Résumé ici :
		Avant de démarrer winpe:
		...\SYSTEM\CurrentControlSet\Control
			ServicesPipeTimeout Dword 300000
		...\SYSTEM\CurrentControlSet\services\termservice\
			start = 4
		IFEO :
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\s-svchost.exe]
;"Debugger"="\\ntsd.exe  -server tcp:port=5901:6000 X:\\Windows\\System32\\s-svchost.exe"
;"Debugger"="\\ntsd.exe  -server tcp:port=5901:6000 -y srv*http://msdl.microsoft.com/download/symbols X:\\Windows\\System32\\s-svchost.exe"
"Debugger"="\\windbg.exe -server tcp:port=5901:6000 -y srv*x:\localsymboles*http://msdl.microsoft.com/download/symbols X:\\Windows\\System32\\s-svchost.exe"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\termservice]
"ImagePath"="X:\\Windows\\System32\\s-svchost.exe -k NetworkService" <<<<--- pour le retourver plus rapidement dasn la liste des tâches 

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server]
;??? valeurs possibles ( si j'ai bien compris le code ) 1, 2, 3, et plus ???
"DebugTS"=dword:1
;"BreakOnRCMStart"=dword:1

		lancement du debugage :
		net start mpssvc           ----------> utilité ???
		regedit /s \IFEO.reg
		sc config termservice start= demand --->>>> vérifier que le service n'a pas demarré		
		net start termservice
		dans une autre boîte cmd :
		\windbg  -remote tcp:port=5901:6000 -y "srv*X:\localSymbols*http://msdl.microsoft.com/download/symbols"

	f- mais comment arriver au point d'entrée de termsvr.dll
		En effet, le debugger "break" une première fois dans le programme "MySvchost" (Svchost renommé pour l'isolé mais avec la version 1709 ce n'est plus utile car MS a "isolé" preque tous les services)
		Ce programme doit ensuite charger termsvr.dll et lui transmettre de dialoguer avec le gestionaire des services
		Et c'est bien termsvr.dll que je souhaite débugger
		Comment aller plus loin ? 
		Peut on mettre un bp sur kernelbase!LoadLibraryExW uniquement lors du chargement de termsvr.dll ?
		Un exemple bien utile ici ( voir la commande BU ): 
			http://read.pudn.com/downloads136/ebook/582565/WinDBG_Cmds.pdf
			bu kernel32!LoadLibraryExW ";as /mu ${/v:MyAlias} poi(@esp+4); .if ( $spat( \"${MyAlias}\", \"*termsrv.dll*\" ) != 0 ) { kn; } .else { gc }"
			non testé !

		Mais on peut être faire mieux avec les paramètres scpéciques contenus dans le code de termsvr.dll

	g - les paramètres de debug de Termservice identifiés dans le code avec IDA
		"System\CurrentControlSet\Control\Terminal Server"
			"DebugTS" et "BreakOnRCMStart" : valeurs possibles de 1,2,3
				call IsDebuggerPresent
					if yes then call DebugBreak
		Donc "g" et termsrv break grâce à la clé DebugTS = 1

		Je modifie le flag et je pose un bp sur un point de passage identifié par le wrapper
			eb termsrv!g_DebugSpewTraceLevel 0xba -->> 0xff
			bp termsrv!CDefPolicy::Query
		Rien de plus !

		La fonction DbgPrintMessage commence par le test d'un flag "g_DebugSpewTraceLevel@@3KA dd 0BAh"
		Analyser un peu le code avec IDA
		Chercher comment neutraliser le saut qui suit le test de ce flag à l'entrée de la fonction 
			un simple jmp (eb) fera le travail
			eb termsrv! .... mais l'offset change selon la base de "relocation" 
			Comment localiser cette adresse mémoire ? 
			u termsrv!_DbgPrintMessage et "u" jusqu'au test 

		La lecture du code montre une variable g_bEnabled. Un peu de recherche dans le code ....
		"System\CurrentControlSet\Control\Terminal Server"
			"EnableTraceCorrelation" dw 1...?
		si "EnableTraceCorrelation" = 1 alors g_bEnabled = 1 mais rien de plus dans ETW pour l'instant

		Et les symboles ne sont pas disponibles.

	h - pourquoi NTSD/windbg ne trouve pas les symboles ?
		la consultation de la pile (avec K) indique une valeur relative au nom d'une fonction exportée et non l'adresse de retour de DebugBreak ?

		N'ayant pas d'autres idées, j'ajoute un répertoire de cache dans le chemin de windbg. Et reboot !
		Toujours pas de symboles

		---->>> seule solution : lancer windbg dans un windows10 normal et charger les symboles dans un cache local, puis les recopier dans un répertoire de winpe qui deviendra le cache de windbg

	Résultat : 
		avec la modification du flag termsrv!g_DebugSpewTraceLevel = 0xff : aucun information supplémentaire visible dans ETW
		Normal car il est ré-initialisé plusieurs fois avec la valeur d'origine (0xBA)
		avec winpe (janvier2018) : pas de break sur termsrv!CDefPolicy::Query 

2 - comment voir les messages envoyés par DbgPrintMessage ?
	En me documentant sur les API utilisées lors du démarrage, je finis par comprendre que les traces utilisent le mécanisme ETW.
	eventwvr.msc permet de visualiser certains log ETW relatif à dans TerminalService-localSessionManager 
		 on peut voir les erreurs mais pas le texte des traces sur la progression de Termsrv.dll vu dans windbg
	Le logiciel dbgview de sysinternals peut il voir les traces : non !

	Recherche sur ETW :
	https://docs.microsoft.com/en-us/dotnet/framework/wcf/samples/etw-tracing
	Le principe reste peut être vrai pour une aplication "no managed" :
		"Before using this listener, an ETW Trace Session must be started. 
		This session can be started by using Logman.exe or Tracelog.exe."
		Il faut un "guid" ou un truc de ce genre.
	tracelog.exe dans le ddk : https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/tracelog-command-syntax
	Logman.exe est disponible dans win10 : https://technet.microsoft.com/en-us/library/bb490956.aspx
		exemple :
		logman create trace Wcf -o <logfilename> -p "{411a0819-c24b-428c-83e2-26b41091702e}" -f bincirc -max 1000
		Logman start Wcf 
		Logman stop Wcf 
		puis conversion du fichier etl en txt ( tracerpt.exe peut être ou voir avec eventvwr.msc )
---------------------------------- ETW : la meilleure explication en quelques mots
https://blogs.msdn.microsoft.com/matt_pietrek/2005/03/23/etw-tracing-how-and-why/
https://blogs.msdn.microsoft.com/matt_pietrek/2004/09/16/intro-to-event-tracing-for-windows/
Il faudrait le fichier .mof mais impossible à trouver je suppose
Il faut absolument le Guid
https://msdn.microsoft.com/en-us/library/windows/desktop/aa364105(v=vs.85).aspx
Si j'ai bien compris, le provider s'enregistre avec RegisterTraceGuids 
	une callback du provider sera appeléé lorsqu'un "consummer" voudra démarrer la capture ( avec  enableTrace )
	Ceci permet au provider de contrôler s'il veut ou non laisser capturer les info.
	Le 3 eme paramètre contient le guid. 
	mais à quoi sert le tableau de guid qui suit ?
	Dans le code de termsrv.dll, la focntion ?Start@CService appelle RegisterTraceGuids.
	Donc le Guid pour termsrv.dll serait :
.rdata:00000001800C08B0 WPP_ThisDir_CTLGUID_RCM dd 5283D5F6h            ; Data1
.rdata:00000001800C08B0                                         ; DATA XREF: CService::Start(void)+3C?o
.rdata:00000001800C08B0                 dw 65B5h                ; Data2
.rdata:00000001800C08B0                 dw 425Fh                ; Data3
.rdata:00000001800C08B0                 db 0A3h, 0Bh, 0F1h, 6Ch, 5, 7Dh, 6Bh, 57h; Data4

	Le guid enregistré lors du démarrage de termsrv.dll est : {5283D5F6-65B5-425F-A30B-F16C057D6B57}
	Mais il manquera le fichier MOF car MS ne doit pas le fournir

3 - nouveau pb avec "logman create trace" : erreur au lancement !!! 
	Le lancement de la commande :
	logman create trace traceTermSrv -o x:\traceTermSrv -p "{5283D5F6-65B5-425F-A30B-F16C057D6B57}" -f bincirc -max 1000
	échoue avec le message :
"Error:
The system cannot find the path specified."

	Cette commande réussit dans un win10 normal.

	Procmon signale le chargement de Pla.dll et Taskschd.dll :
		Je mets en place les services Schedule et PLA (quelques fichiers manquants). 
		PLA démarre mais Schedule ne démarre pas ( peut être pas utile si on n'utilise pas les commande de la planification de logman)

	Une commande qui fonctionne :
		"logman query providers -pid 'le pid de MySvchost.exe' 
		et qui affichera bien {5283D5F6-65B5-425F-A30B-F16C057D6B57} parmi d'autres guid.

4 - Comparaison avec le fonctionnement dans un win10 normal
	Procmon montre plus de symboles lors de la consultation de la "stack" dans un windows10 normal.
	Je suppose qu'il rencontre la même anomalie que windbg.
	Windgb permet de mettre les symboles de logman dans le cache local des symboles de windows10 normal.
	Je le recopie dans le cache des symboles de winpe
	Je teste dans winpe en rajoutant la ligne relative au cache local dans procmon : sans résultat.
	Windbg de winpe utilise vraiment les symboles de logman.pdb "recopié".

5 - le message  d'erreur lors du téléchargement des symboles de windbg dans winpe 
!sym noisy 
0:000> ld logman
SYMSRV:  BYINDEX: 0x2
         x:\localsymbols*http://msdl.microsoft.com/download/symbols
         logman.pdb
         EDEC3AE96F5FC932D858FFF720C0E38E1
SYMSRV:  UNC: x:\localsymbols\logman.pdb\EDEC3AE96F5FC932D858FFF720C0E38E1\logman.pdb - path not found
SYMSRV:  UNC: x:\localsymbols\logman.pdb\EDEC3AE96F5FC932D858FFF720C0E38E1\logman.pd_ - path not found
SYMSRV:  UNC: x:\localsymbols\logman.pdb\EDEC3AE96F5FC932D858FFF720C0E38E1\file.ptr - path not found
SYMSRV:  store http://msdl.microsoft.com/download/symbols - Catastrophic failure   <<<<<----- !!!!! ????
SYMSRV:  RESULT: 0x80004005
DBGHELP: X:\Windows\System32\logman.pdb - file not found
DBGHELP: logman.pdb - file not found
*** ERROR: Module load completed but symbols could not be loaded for logman.exe
DBGHELP: logman - no symbols loaded
Symbols loaded for logman

	Wireshark ne voit rien sur le réseau : donc il manque une brique dans http de mon winpe
	En raison de la "Catastrophic failure", windbg prend les quelques informations disponibles dans l'exe lui même comme par exemple le nom des fonctions exportées et leur adresses

	en résumé, après un mois passé sur le sujet, je suis face à 2 erreurs dans winpe:
		- logman ne fonctionne pas
		- le téléchargement des symboles de windbg échoue ( mais le mécanisme du cache fonctionne )

6 - test avec la version "full-flat" : une installation de windows10 modifiée pour devenir un winpe
	J'ai un mode d'emploi pour créer cette version "full-flat".
	le test :
		logman create trace et service schedule désactivé et arrêté : NO OK
		Net start schedule :  OK
		logman create trace : OK
	le fichier etl est créé mais vide car je n'ai pas pris le temps de modifier avec termservice (clé et windbg pour neutraliser le flag BA )
	Mais le téléchargement des symboles échoue : pas très grave car j'ai le cache dans l'autre VM

	TODO : chercher les différences pour schedule

	Premiers éléments de réflexion :
		ruche software de mon winpe  : ruche software de install.wim avant installation
		ruche software de "full-flat": ruche software aprés installation et modifiée pour devenir winpe 
			trés peu de modif pour winpe
			certainement beaucoup de modif par l'installation
		ruche system de mon winpe    : ruche de ADK avec quelques ajouts de MicroWinBuilder
		ruche system de "full flat"  : ruche system aprés installation et modifiée pour devenir winpe
			
		fichiers : un peu plus nombreux dans "full-flat"

	Vérifié : "logman create trace ..." échoue si schedule est arrêté !

7 - Test avec termservice et windbg et logman dans la version "full-flat"
	La mise en oeuvre a été un peu longue. Mais rien dans lichier etl. Pourquoi ?
	analyse du code de DoWppTrace :
	En cherchant un peu, je trouve que DoWppTrace réalise les "call    cs:__imp_EtwTraceMessage"
	En modifiant le test avec windbg, le fichier etl se remplit un peu !
.text:0000000180042F7F loc_180042F7F:                          ; CODE XREF: DoWppTrace+3C7B7?j
.text:0000000180042F7F                 mov     rcx, cs:WPP_GLOBAL_Control  ------> init à WPP_GLOBAL_Control
.text:0000000180042F86                 lea     rax, WPP_GLOBAL_Control     ------> = WPP_MAIN_CB aprés enregistrement
.text:0000000180042F8D                 cmp     rcx, rax
.text:0000000180042F90                 jz      locret_180006701
.text:0000000180042F96                 test    [rcx+1Ch], edx -------->>>> WPP_MAIN_CB + 1Ch 
.text:0000000180042F99                 jz      locret_180006701

8 - analyse du code de la callback car elle modifie ces variables ( crossreference )
Au démarrage du service "termsrv.dll" : CService::Start(CService *__hidden this)
	enregistrement du guid  et de la callback pour le mécanisme ETW
		WppControlCallback sera appelée par un logiciel comme "logman" crée/active une trace avec EnableTrace
		https://msdn.microsoft.com/en-us/library/windows/desktop/aa363710(v=vs.85).aspx 
"You can call this function one time to enable a provider before the provider registers itself. 
After the provider registers itself, ETW calls the provider's ControlCallback function. 
...
To determine the level and keywords used to enable a manifest-based provider, use one of the following commands:
Logman query providers <provider-name>
Wevtutil gp <provider-name>"
			-->>> On peut lancer "logman create" et "logman start" avant le démarrage de termsrv.dll
	Donc lors de "logman start ...", la callback est appelée.
	Le provider termserv demande alors le niveau de détail souhaité par le "consummer/controler" logman.
	The GetTraceEnableFlags function retrieves the enable flags passed by the controller to indicate which category of events to trace.
	Returns the value the controller specified in the EnableFlag parameter when calling the EnableTrace function.
	https://msdn.microsoft.com/en-us/library/windows/desktop/aa363693(v=vs.85).aspx
	"ETW does not pass the enable flags and enable level that the controller passes to the EnableTrace function to this callback. 
	To retrieve this information, call the GetTraceEnableFlags and GetTraceEnableLevel functions, respectively."
	je ne comprends pas la signification des flags de GetTraceEnableFlags 
	Les valeurs définies par EnableTrace : 
	https://msdn.microsoft.com/en-us/library/windows/desktop/aa363710(v=vs.85).aspx
	1 = TRACE_LEVEL_CRITICAL 2 = TRACE_LEVEL_ERROR 3 = TRACE_LEVEL_WARNING 4 = TRACE_LEVEL_INFORMATION 5 = TRACE_LEVEL_VERBOSE
	C'est donc logman qui doit définir ce niveau de détail. A voir comment plus tard !
	
	la callback modifie en conséquence la variable g_DebugSpewTraceLevel et de WPP_MAIN_CB + ... 
	Un peu de pratique avec windbg:
		"logman start" déclenche la callback avec rcx = 4 et rdx = WPP_MAIN_CB
			g_DebugSpewTraceLevel = 0 
			WPP_MAIN_CB+1Ch = 0

 
A retenir :
	lancer "logman create" et "logman start" avant "net start termservice" !

Résumé pour obtenir une trace avec wnpe "full-flat" :
	une clé active les traces. Sa valeur est stockée dans une variable globale
	la variable g_DebugSpewTraceLevel contrôle le niveau de détail de la trace
	termsrv!_DbgPrintMessage commence par le test de g_DebugSpewTraceLevel 
	ensuite DoWppTrace lance ou non l'enregistrement d'une trace selon la valeur de WPP_MAIN_CB + 1Ch 
TODO:	c'est le "controler" (logman) qui définit le niveau de détail avec le paramètre :
		-p { GUID | provider [( flags [ ,flags ... ])] Level ]
TODO:	Trouver un exemple pour mettre en oeuvre ce paramètre

TODO: faire le test dans winpe "full-flat"

Partie logman et fichier etl:
	les paramètres de logman :
	https://technet.microsoft.com/en-us/library/bb490956.aspx?f=255&MSPPError=-2147217396

	pour lire le fichier etl : 
	Tracerpt.exe is the tool to view the content of an ETW event log file and available on all supported platforms. It can be used to generate CSV	
	
	pour les flags et level de logman
	https://msdn.microsoft.com/en-us/library/windows/desktop/dd815339%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
"The provider is normally registered during setup. However it can also be manually registered by running wevtutil.exe im <ManifestFileName> (on Windows Vista and Later) or mofcomp.exe <MofFileName> (on XPSP2 and W2K3). 
Flags can be used to filter the traces by their kind. It can be OR'd value of the following trace kinds. 
If not supplied, all trace kinds are enabled. 
0x1 - API entry/exit traces. 
0x2 - Error traces. 
0x4 - IO traces. 
0x8 - SOAP message traces. 
0x10 - Binary message traces. 
Level can be used to filter the traces by their level. It should be one of the following values. 
If not supplied, all trace levels are enabled. 
0x1 - Fatal traces. 
0x2 - Error traces. 
0x3 - Warning traces. 
0x4 - Informational traces. 
0x5 - Verbose traces. "

	Avec la commande :
	logman create trace traceTermSrv -o x:\traceTermSrv -p "{5283D5F6-65B5-425F-A30B-F16C057D6B57}" 0xFFFF 5 -f bincirc -max 1000
	la callback reçoit les mêmes données qu'avant mais GetTraceEnableFlags and GetTraceEnableLevel reçoivent bien les paramètres passés à logman
			g_DebugSpewTraceLevel = 0xffff 
			WPP_MAIN_CB+1Ch = 0xffff
	Le fichier etl n'est pas enrichi avec de nouvelles infos ( entrée, sortie de fonction )
	vérifier si le code qui traite entrée/sortie de fonction est sollicté :
		si rcx = 1000h alors le code pourrait afficher ">>>:"
		Mais il n'y aucun appel de termsrv!_DbgPrintMessage avec cette valeur.
	Peut être faut il la version dite "checked" des binaires?

Conclusion :
	Comme attendu, sans les mof, Tracerpt.exe comme eventvwr.msc ne lisent rien.
	Le fichier ETL contient des info mais il est difficile de les interprèter:
		les chaînes de texte sont elles dans le bon ordre et avec tous les paramètres ?
	Le suivi des fonctions ne semble pas disponible.









-------------------------------------------------des sites :

https://blogs.msdn.microsoft.com/ntdebugging/2007/07/26/lpc-local-procedure-calls-part-1-architecture/
exercices avec windbg
https://blogs.msdn.microsoft.com/ntdebugging/2008/
http://read.pudn.com/downloads136/ebook/582565/WinDBG_Cmds.pdf

un script pour windbg : à comprendre un jour
https://blogs.msdn.microsoft.com/debuggingtoolbox/2007/05/23/windbg-script-disabling-isdebuggerpresent/

pour w2000
https://support.microsoft.com/en-us/help/824344/how-to-debug-windows-services
en 2010
https://bugslasher.net/2011/03/26/how-to-debug-a-process-as-soon-as-it-starts-with-windbg-or-visual-studio-2010/
https://bugslasher.net/2010/10/14/how-to-debug-a-windows-service/

api win32
http://www.geoffchappell.com/notes/windows/shell/events/core.htm?tx=14&ts=0,60&tw=26%25

undoc win32api
http://undoc.airesoft.co.uk/

windbg et .net
https://blogs.msdn.microsoft.com/kaevans/2011/04/11/intro-to-windbg-for-net-developers/

MSERROR
https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-ERREF/[MS-ERREF].pdf

big api NtQuerySystemInformation
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724509%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
http://www.exploit-monday.com/2013/06/undocumented-ntquerysysteminformation.html

OP CODE ASM 
https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf

Boot en 2007
https://blogs.msdn.microsoft.com/ntdebugging/2007/06/28/how-windows-starts-up-part-the-second/

-----------------------------
Remote debugging with WinDbg and NTSD 
You probably know that NTSD and WinDbg debuggers (both part of Debugging Tools for Windows) form a powerful combination for remote debugging scenarios. You can start NTSD on a remote system, and then connect to it from WinDbg, using sockets or pipes. What is interesting is that the same configuration can be used on a single machine, when we need to debug processes running in non-interactive sessions. Yes, for example, services. Image File Execution Options can help us here again. Lets assume that Debugging Tools package is installed on our system in c:\dbgtools directory. Now we can use IFEO to configure our service to start under NTSD debugger: 

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\myservice.exe
  Debugger = "c:\dbgtools\ntsd.exe -server tcp:port=5001:6000" (REG_SZ)

Note “-server tcp:port=5001:6000” options – they ask NTSD debugger to select any free port in the specified range (5001..6000 in this case) and start listening for a socket connection. 
When we try to start our service, NTSD is launched instead. Now we can use WinDbg to connect to NTSD using sockets and debug: 

>windbg.exe -remote tcp:server=localhost,port=5001:6000

After WinDbg has connected to NTSD, we can set breakpoints wherever necessary, and let the service process continue. Now we can debug the startup code of our service even if it is running under a non-administrative user account. 
Finally it looks like we have found the ultimate solution? Yes, almost. The only two problems I see with this approach are the following: 
We have to use WinDbg and cannot use Visual Studio debugger 
After we have started our service under NTSD, we cannot opt out of debugging; we have to connect WinDbg to NTSD and manually let our service run, even if this time we do not want to debug it 

StartDbg  "http://www.debuginfo.com/tools/startdbg.html"
Being a long time fan of Visual Studio debugger (mostly for its productive and logical user interface), I wanted to use it to debug services of any kind, including those that run under non-administrative user accounts. Therefore, I wrote a simple tool, StartDbg, which allows me to do it. 
The idea behind StartDbg is simple – we start it instead of our target service, and use it to start our service in suspended state, so that we could have enough time to attach Visual Studio debugger before our service's startup code starts executing. Assume that our service's ImagePath entry in Registry currently contains "c:\myapps\myservice.exe". To use StartDbg, we change it to "c:\startdbg\startdbg.exe c:\myapps\myservice.exe". As a result, when we start our service (for example, using Services applet), startdbg.exe will be started instead, and will receive "c:\myapps\myservice.exe" as a command line parameter. 
Here is the list of actions performed by StartDbg: 
Start the service using CreateProcess function, in suspended state (using CREATE_SUSPENDED flag). 
Inject a small piece of code into the service process' address space. 
Hijack the service's main executable's entry point and modify it to point to the injected piece of code. 
Resume the service (it will pass control to the injected piece of code). 
The injected code will suspend the service again, this time by calling Sleep function with a predefined timeout. While the service is suspended, we can attach the debugger to the service's process and set breakpoints. 
After the timeout has expired, injected code returns from the sleeping state and lets the service continue normally by passing control to the original entry point. 

(The real implementation is a bit more complicated than that, to provide better status reporting) 
Here you can find more information about StartDbg, including detailed usage instructions, as well as its source code. 
StartDbg is not without limitations, though – it does not allow us to debug the entry points of the DLLs loaded by the service at startup (and we have to fall back to NTSD/WinDbg combination if we need to do it). 
------------------------------ break on loadlibrary d'une dll : attention g ou gc ?
LoadLibraryExW( MYDLL ) called? -> Break only if LoadLibrary is called for MyDLL
bu kernel32!LoadLibraryExW ";as /mu ${/v:MyAlias} poi(@esp+4); .if ( $spat( \"${MyAlias}\", \"*MYDLL*\" ) != 0 ) { kn; } .else { g }"
The first parameter to LoadLibrary (at address ESP + 4) is a string pointer to the DLL name in question.
The MASM $spat operator will compare this pointer to a predefined string-wildcard, this is *MYDLL* in our example.
Unfortunately $spat can accept aliases or constants, but no memory pointers. This is why we store our string in question to an alias (MyAlias)
first.
Our kernel32!LoadLibraryExW breakpoint will hit only if the pattern compared by $spat matches. Otherwise the application will continue
executing.
---------------------------------------------Annexes
Annexe : info relatives à Windbg ( s'appliquent aussi à NTSD )
exemple de transport réseau "namedpipe" (local) ou "tcp" (très éloigné) :
"C:\outils-sdk\ntsd.exe" -server npipe:pipe=montoto c:\windows\system32\notepad.exe
"C:\outils-sdk\ntsd.exe" -server tcp:port=5001:6000 c:\windows\system32\notepad.exe

A propos du chargement des symboles de windbg :
srv*http://msdl.microsoft.com/download/symbols
https://stackoverflow.com/questions/30019889/how-to-set-up-symbols-in-windbg
windbg -y "srv*http://msdl.microsoft.com/download/symbols"
et avec un cache pour une utilisation future de windbg dans winpe 
windbg -y "srv*X:\SymCache*http://msdl.microsoft.com/download/symbols"

un résumé des commandes de windbg
http://read.pudn.com/downloads136/ebook/582565/WinDBG_Cmds.pdf

-------------- Les extensions de windbg
	quels fichiers ?
	valables avec la combinaison de NTSD ?
-------------- site ms
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/symbol-stores-and-symbol-servers
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/windbg-command-line-options
extension dans windbg
https://en.wikipedia.org/wiki/WinDbg
installation des symboles
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/installing-windows-symbol-files

---------------- test
"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe"  -y "srv*C:\SymCache*http://msdl.microsoft.com/download/symbols"

http://msdl.microsoft.com/download/symbols/index2.txt
