Dans ce post nous allons voir comment traiter un problème spécifique de 100% CPU causé par le spooler.

Après avoir constaté via Task Manager ou Process Explorer que le processus causant cette consommation de temps processeur était bien Spoolsv.exe (spooler d’impression), nous avons pris plusieurs dumps du processus avec l’outil Adplus.

Cette méthodologie peut être reprise pour identifier d’autres dysfonctionnements liés au spooler.

 

Collecte de dump

Pour cela, télécharger les « Debugging Tools » à cette adresse : http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx et les installer sur le serveur (il est possible d’installer ces outils sur une machine moins sensible puis de copier le répertoire d’installation vers le serveur).

Après avoir installé ces outils nous avons pris des dumps du processus Spoolsv.exe via la commande suivante :

Cscript Adplus.vbs –quiet –hang –pn spoolsv.exe –r 3 60

• -quiet => afin de ne pas avoir à répondre aux deux messages « popup » concernant les symbols
• -hang => vous avez le choix entre hang ou crash, dans notre cas comme nous voulons prendre des dumps sans interrompre le processus nous utilisons donc –hang.
• -pn=> cette option permet de spécifier le nom du processus, sinon vous pouvez utiliser –p en spécifiant le PID du process.
• -r => permet d’automatiser la prise de plusieurs dumps avec un intervalle de temps entre chaque dump, ici 3 dumps avec 60s entre chaque dump.

Après avoir pris les dumps, nous les avons ouverts avec Windbg (fournis aussi avec les Debugging tools) :

1. Menu Démarrer => Debugging tools for Windows => Windbg
2. Depuis le menu File => Symbol file path entrez les paramètres suivants : SRV*C:\SYMBOLS*http://msdl.microsoft.com/download/symbols puis OK
   Il est important de disposer de symboles pour que Windbg puisse interpréter le contenu de la mémoire, de la pile, etc…On spécifie ici la source utilisée pour télécharger les symboles publics (en l’occurrence les serveurs publics Microsoft)
3. File=> Open Crash Dump

 

Analyse des dumps

La première étape consiste à rechercher le thread consommant le plus de CPU :

>!runaway

User Mode Time

Thread Time

4:1144 0 days 0:00:01.312 => Le thread 4 est celui qui utilise actuellement le plus de CPU

11:135c 0 days 0:00:00.015

17:1714 0 days 0:00:00.000

16:1710 0 days 0:00:00.000

15:170c 0 days 0:00:00.000

14:1708 0 days 0:00:00.000

13:1704 0 days 0:00:00.000

12:1700 0 days 0:00:00.000

10:16fc 0 days 0:00:00.000

9:16f8 0 days 0:00:00.000

8:16f0 0 days 0:00:00.000

7:16e8 0 days 0:00:00.000

6:16ac 0 days 0:00:00.000

5:113c 0 days 0:00:00.000

3:15c8 0 days 0:00:00.000

2:ff4 0 days 0:00:00.000

1:13c 0 days 0:00:00.000

0:148 0 days 0:00:00.000

Nous devons donc nous positionner dans le contexte du thread :

>~4s

eax=0000004b ebx=00000000 ecx=00a3dea8 edx=7ffe0300 esi=00a3e008 edi=00000000

eip=7c8285ec esp=00a3df94 ebp=00a3dfd4 iopl=0 nv up ei pl nz na pe nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206

ntdll!KiFastSystemCallRet:

7c8285ec c3 ret

On affiche la pile du thread :

>kv

ChildEBP RetAddr Args to Child

00a3df90 7c82734b 77f5cd00 00a3dfe0 00010000 ntdll!KiFastSystemCallRet (FPO: [0,0,0])

00a3df94 77f5cd00 00a3dfe0 00010000 00a3dfb4 ntdll!ZwOpenKey+0xc (FPO: [3,0,0])

00a3dfd4 77f5cc4d 0000047c 00000000 00000000 advapi32!LocalBaseRegDeleteKeyEx+0xb0 (FPO: [Non-Fpo]) (CONV: stdcall)

00a3dfec 77f5cc0d 0000047c 00a3e008 00a3e2c4 advapi32!LocalBaseRegDeleteKey+0x14 (FPO: [Non-Fpo]) (CONV: stdcall)

00a3e038 7616687e 0000047c 00a3e2c4 00a3e288 advapi32!RegDeleteKeyW+0xd2 (FPO: [Non-Fpo]) (CONV: stdcall)

00a3e048 7613e295 0000047c 00a3e2c4 008f52a8 localspl!SplRegDeleteKey+0x3d (FPO: [Non-Fpo]) (CONV: stdcall)

00a3e288 7613e234 0000047c 000001e0 00a3e2c4 localspl!SplRegDeleteKey+0x17b (FPO: [Non-Fpo]) (CONV: stdcall)

00a3e4d0 7613e234 00000478 0000047c 00a3e50c localspl!SplRegDeleteKey+0x126 (FPO: [Non-Fpo]) (CONV: stdcall)

00a3e718 7613e234 00000480 00000478 00a3e754 localspl!SplRegDeleteKey+0x126 (FPO: [Non-Fpo]) (CONV: stdcall)

00a3e960 76143a57 00000174 00000480 008f9e78 localspl!SplRegDeleteKey+0x126 (FPO: [Non-Fpo]) (CONV: stdcall)

00a3e990 76143ac2 008f9e78 008f52a8 008f52a8 localspl!DeletePrinterIni+0x7a (FPO: [Non-Fpo]) (CONV: stdcall)

00a3e9a8 7613f590 00958078 00000001 00000000 localspl!DeletePrinterForReal+0x2b (FPO: [Non-Fpo]) (CONV: stdcall)

00a3e9bc 76133674 008f52a8 008f52a8 00a3f68c localspl!CleanupDeletedPrinters+0x2b (FPO: [Non-Fpo]) (CONV: stdcall)

00a3f230 761374eb 008f52a8 00000000 008f2ab8 localspl!BuildPrinterInfo+0xee5 (FPO: [Non-Fpo]) (CONV: stdcall)

00a3f668 761391f8 0090e8a0 00000001 00a3f68c localspl!SplCreateSpooler+0x644 (FPO: [Non-Fpo]) (CONV: stdcall)

00a3f908 74064c44 008f2ab8 00000158 00000000 localspl!InitializePrintProvidor+0x1bc (FPO: [Non-Fpo]) (CONV: stdcall)

00a3f930 74064915 74064cd0 00000000 00000000 spoolss!InitializeProvidor+0x89 (FPO: [Non-Fpo]) (CONV: stdcall)

00a3ffb8 77e64829 008f1ea8 00000000 00000000 spoolss!InitializeRouter+0x25b (FPO: [Non-Fpo]) (CONV: stdcall)

00a3ffec 00000000 01003f90 008f1ea8 00000000 kernel32!BaseThreadStart+0x34 (FPO: [Non-Fpo]) (CONV: stdcall)

Ici on peut voir que nous essayons de faire une suppression d’une clé de registre, localspl!SplRegDeleteKey, et cela en boucle car il semble que le processus n’arrive pas à la supprimer, d’où la consommation de CPU dans le temps.

Voyons à quoi correspond cette clé (du moins trouver l’adresse du handle qui pointe vers cette clé) avec la commande suivante :

>Kp

ChildEBP RetAddr

00a3df90 7c82734b ntdll!KiFastSystemCallRet(void)

00a3df94 77f5cd00 ntdll!ZwOpenKey(void)+0xc

00a3dfd4 77f5cc4d advapi32!LocalBaseRegDeleteKeyEx(struct HKEY__ * hKey = 0x0000047c, struct _UNICODE_STRING * lpSubKey = 0x00000000, unsigned long samDesired = 0, unsigned long Reserved = 0)+0xb0

00a3dfec 77f5cc0d advapi32!LocalBaseRegDeleteKey(struct HKEY__ * hKey = 0x0000047c, struct _UNICODE_STRING * lpSubKey = 0x00a3e008 "(0x1A01)")+0x14

00a3e038 7616687e advapi32!RegDeleteKeyW(struct HKEY__ * hKey = 0x0000047c, unsigned short * lpKeyName = 0x00a3e2c4)+0xd2

00a3e048 7613e295 localspl!SplRegDeleteKey(void * hKey = 0x0000047c, unsigned short * pszSubKey = 0x00a3e2c4, struct _INISPOOLER * pIniSpooler = 0x008f52a8)+0x3d

00a3e288 7613e234 localspl!SplDeleteThisKey(void * hParentKey = 0x0000047c, void * hThisKey = 0x000001e0, unsigned short * pThisKeyName = 0x00a3e2c4, int bDeleteNullKey = 1, struct _INISPOOLER * pIniSpooler = 0x008f52a8)+0x17b

00a3e4d0 7613e234 localspl!SplDeleteThisKey(void * hParentKey = 0x00000478, void * hThisKey = 0x0000047c, unsigned short * pThisKeyName = 0x00a3e50c, int bDeleteNullKey = 1, struct _INISPOOLER * pIniSpooler = 0x008f52a8)+0x126

00a3e718 7613e234 localspl!SplDeleteThisKey(void * hParentKey = 0x00000480, void * hThisKey = 0x00000478, unsigned short * pThisKeyName = 0x00a3e754, int bDeleteNullKey = 1, struct _INISPOOLER * pIniSpooler = 0x008f52a8)+0x126

00a3e960 76143a57 localspl!SplDeleteThisKey(void * hParentKey = 0x00000174, void * hThisKey = 0x00000480, unsigned short * pThisKeyName = 0x008f9e78, int bDeleteNullKey = 1, struct _INISPOOLER * pIniSpooler = 0x008f52a8)+0x126

00a3e990 76143ac2 localspl!DeletePrinterIni(struct _INIPRINTER * pIniPrinter = 0x008f9e78)+0x7a

00a3e9a8 7613f590 localspl!DeletePrinterForReal(struct _INIPRINTER * pIniPrinter = 0x00958078, int bIsInitTime = 1)+0x2b

00a3e9bc 76133674 localspl!CleanupDeletedPrinters(struct _INISPOOLER * pIniSpooler = 0x008f52a8)+0x2b

00a3f230 761374eb localspl!BuildPrinterInfo(struct _INISPOOLER * pIniSpooler = 0x008f52a8, int UpdateChangeID = 0)+0xee5

00a3f668 761391f8 localspl!SplCreateSpooler(unsigned short * pMachineName = 0x0090e8a0, unsigned long Level = 1, unsigned char * pSpooler = 0x00a3f68c "", unsigned char * pReserved = 0x00000000 "")+0x644

00a3f908 74064c44 localspl!InitializePrintProvidor(struct _PRINTPROVIDOR * pPrintProvidor = 0x008f2ab8, unsigned long cbPrintProvidor = 0x158, unsigned short * pFullRegistryPath = 0x00000000)+0x1bc

00a3f930 74064915 spoolss!InitializeProvidor(unsigned short * pProvidorName = 0x74064cd0, unsigned short * pFullName = 0x00000000)+0x89

00a3ffb8 77e64829 spoolss!InitializeRouter(struct RouterInitializationParams * pRouterParams = 0x008f1ea8)+0x25b

00a3ffec 00000000 kernel32!BaseThreadStart(<function> * lpStartAddress = 0x01003f90, void * lpParameter = 0x008f1ea8)+0x34

La commande suivante permet d’afficher la clé de registre qui ne peut être supprimée :

>!handle 0000047c 4

Handle 0000047c

Name \REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\bg-picklabel on bgmprint (from BG-JLP) in session 1\PrinterDriverData\Papers

Cette clé est vraisemblablement corrompue car la tentative de suppression manuelle avec Regedit s’est avérée impossible. Le nom de la clé est peu commun et peut donc contenir des caractères null.

La suppression via Regedit n'étant pas possible nous avons utilisé l'outil RegDelNull.exe (disponible depuis http://www.microsoft.com/technet/sysinternals/utilities/regdelnull.mspx ) via la commande : RegDelNull.exe hklm -s puis nous avons répondu « Yes » concernant la suppression de la clé « bg-picklabel on bgmprint (from BG-JLP) in session 1\PrinterDriverData\Papers »

Un redémarrage du spooler a permis de remettre en service le service d’impression.

 

Philippe

Windows Core Support Escalation Engineer

Après nous être concertés longuement, nous sommes tombés d’accord sur ce que nous pouvions vous souhaiter pour l’année à venir.

Tout ce que nous espérons pour vous c’est de n’être impactés que par peu de problèmes (suffisament pour nous permettre de vous aider et de toujours faire ce métier passionnant) et surtout nous ne vous en voudrons pas si la complexité des incidents que vous nous remontez baisse un peu l’an prochain, cela nous permettra de souffler un peu !

 

Plus traditionnellement, meilleurs voeux, bonne santé et réussite pour vous et vos proches !

Restez connectés !

 

L’équipe de Support Windows Core

Nous allons analyser ensemble un dump relatif à des problème de crash réguliers sur un serveur de fichiers.

D’abord, regardons sur quel type de serveur le crash s’est produit :

0: kd> vertarget

Windows Server 2003 Kernel Version 3790 (Service Pack 1) MP (4 procs) Free x86 compatible

Product: Server, suite: TerminalServer SingleUserTS

Built by: 3790.srv03_sp1_rtm.050324-1447

Kernel base = 0x80800000 PsLoadedModuleList = 0x808af988

Debug session time: Tue Oct 21 02:22:03.749 2008 (GMT+2)

System Uptime: 6 days 7:23:43.156

Il s’agit donc d’un serveur 2003 en SP1, un premier plan d’action serait de le mettre à jour en SP2 :-)

D’autre part, le serveur semble avoir tourné pendant 6 jours avant la génération du dump.

Aussi, chaque crash ou stop est associé un code qui définie le type de problème rencontré, examinons le stop en question :

0: kd> .bugcheck

Bugcheck code 0000007F

Arguments 00000008 80042000 00000000 00000000

C’est un stop 7F avec le paramètre  00000008 ….intéressant !!

Les documents techniques qui détaillent ce type de stop, font référence à un problème de stack overflow :

“Bug Check 0x7F: UNEXPECTED_KERNEL_MODE_TRAP

The UNEXPECTED_KERNEL_MODE_TRAP bug check has a value of 0x0000007F. This bug check indicates that the Intel CPU generated a trap and the kernel failed to catch this trap.

This trap could be a bound trap (a trap the kernel is not permitted to catch) or a double fault (a fault that occurred while processing an earlier fault, which always results in a system failure).

0x00000008, or Double Fault, indicates that an exception occurs during a call to the handler for a prior exception. Typically, the two exceptions are handled serially. However, there are several exceptions that cannot be handled serially, and in this situation the processor signals a double fault. There are two common causes of a double fault:
A kernel stack overflow Or A hardware problem”

Ok, nous savons maintenant qu’il peut s’agir d’un stack overflow ..il va falloir se mettre sur le thread qui a causé le crash pour en savoir plus :

0: kd> .tss 0x28

eax=854b8300 ebx=854b8310 ecx=00000003 edx=89756000 esi=89fc3f30 edi=89756000

eip=bae30bf7 esp=f78f7f88 ebp=f78f81b8 iopl=0         nv up ei ng nz na pe nc

cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010286

q57xp32+0x9bf7:

bae30bf7 53              push    ebx

0: kd> .thread

Implicit thread is now 8ab868d0

0: kd> !thread

THREAD 8ab868d0  Cid 0004.0048  Teb: 00000000 Win32Thread: 00000000 RUNNING on processor 0

IRP List:

    859c0370: (0006,0220) Flags: 00000010  Mdl: 00000000

    85391008: (0006,0220) Flags: 00000884  Mdl: 00000000

    8a02af68: (0006,0094) Flags: 00000000  Mdl: 00000000

Not impersonating

DeviceMap                 d6402818

Owning Process            8ab8a238       Image:         System

Wait Start TickCount      34881482       Ticks: 0

Context Switch Count      21126271            

UserTime                  00:00:00.000

KernelTime                00:03:14.531

Start Address nt!ExpWorkerThread (0x8083f671)

Stack Init f78fb000 Current f78f9150 Base f78fb000 Limit f78f8000 Call 0

Priority 12 BasePriority 12 PriorityDecrement 0

ChildEBP RetAddr  Args to Child             

00000000 bae30bf7 00000000 00000000 00000000 nt!_KiTrap08+0x75 (FPO: TSS 28:0)

WARNING: Stack unwind information not available. Following frames may be wrong.

f78f81b8 bae29c53 89756000 89fc3f30 8975bf54 q57xp32+0x9bf7

f78f8200 bae29edb 854b8310 f78f8278 f78f8248 q57xp32+0x2c53

f78f8210 bae2a199 02756000 878032e0 897ef950 q57xp32+0x2edb

f78f8248 f76ee804 00000001 f78f8278 00000000 q57xp32+0x3199

f78f8260 80a7a24f 897ef850 00000000 86e62a20 NDIS!ndisMProcessSGList+0x90

f78f828c f76ee6fe 86e62a20 897ef850 878032c0 hal!HalBuildScatterGatherList+0x1c7

f78f82e4 f76d249d 8a3d5008 854b8310 862fe230 NDIS!ndisMAllocSGList+0xd9

f78f8300 ba782f37 89e90290 854b8310 89d16c48 NDIS!ndisMSendX+0x1a0

f78f8328 ba78223a 8a3d5008 854b8310 8638eae8 tcpip!IPRcvComplete+0x12d3

f78f8350 ba782622 8638ea02 f78f8402 00000001 tcpip!IPRcvComplete+0x5d6

f78f848c ba783c01 ba7bbbb8 862fe2a4 862fe230 tcpip!IPRcvComplete+0x9be

f78f84fc ba783da0 f3b3f555 00000002 875d30c0 tcpip!IPRcvComplete+0x1f9d

f78f8524 ba784478 00000001 00000000 00000002 tcpip!IPRcvComplete+0x213c

f78f8558 bab209ac 875d3008 89443364 89d2d540 tcpip!IPRcvComplete+0x2814

f78f857c bab29a46 89e8e000 89429058 89e8e000 msiscsi+0x99ac

f78f8624 bab2c101 01429058 84f25502 84f2552c msiscsi+0x12a46

f78f8644 bab1a435 808a5180 84f25502 00000000 msiscsi+0x15101

f78f866c bab036ca 8a02b65c 89e8e000 f78f8698 msiscsi+0x3435

f78f867c bab03afc 897c31a0 84f2552c 884b7d28 iscsiprt!RaCallMiniportStartIo+0x1e

f78f8698 bab0c182 84f2552c 870a48a0 89d17e18 iscsiprt!RaidAdapterPostScatterGatherExecute+0x5e

f78f86b8 bab07823 00000000 00000001 00000000 iscsiprt!RaUnitStartIo+0xc4

f78f86d8 bab0b575 89d17e18 014b7d28 00000000 iscsiprt!RaidStartIoPacket+0x49

f78f86fc bab0c8a6 89d17d30 884b7d28 84c6d270 iscsiprt!RaidUnitSubmitRequest+0x63

f78f8718 bab06844 89d17d30 884b7d28 f78f873c iscsiprt!RaUnitScsiIrp+0x92

f78f8728 8083f9d0 89d17c78 884b7d28 89e8caa0 iscsiprt!RaDriverScsiIrp+0x2a

f78f873c f7409440 884b7d28 884b7dfc 884b7d28 nt!IofCallDriver+0x45

f78f8764 f74094e0 89cfba88 884b7d28 884b7d28 mpio!MPIOReadWrite+0x19e

f78f8830 f7409b34 89cfba88 84c6d1f0 884b7dd8 mpio!MPIOPdoHandleRequest+0x76

f78f8848 f7408945 89cfbb40 884b7d28 884b7d28 mpio!MPIOPdoInternalDeviceControl+0x3c

f78f8870 f740916f 89cfba88 89cfbd78 01000000 mpio!MPIOPdoCommonDeviceControl+0x1fb

f78f8890 f74062ef 89cfba88 884b7d28 f78f88b4 mpio!MPIOPdoDispatch+0x8f

f78f88a0 8083f9d0 89cfba88 884b7d28 84f25480 mpio!MPIOGlobalDispatch+0x19

f78f88b4 f7139a20 84f25480 68d0e000 f78f88f8 nt!IofCallDriver+0x45

f78f88c4 f7139635 84f25480 89419b70 85a52e2c CLASSPNP!SubmitTransferPacket+0xbb

f78f88f8 f7139712 00000000 00001000 85a52e50 CLASSPNP!ServiceTransferRequest+0x1e4

f78f891c 8083f9d0 89419ab8 00000000 8ab96b38 CLASSPNP!ClassReadWrite+0x159

f78f8930 f74d80cf 8756c3a8 85a52e50 f78f8954 nt!IofCallDriver+0x45

f78f8940 8083f9d0 893e7780 85a52cc0 85a52cc0 PartMgr+0x10cf

f78f8954 f73b4802 890bd008 8756c3a8 89595d08 nt!IofCallDriver+0x45

La, il n’y a pas de doute, nous somme bien en présence d’un beau “stack overflow”.

En effet, chaque thread a le droit à un espace limité pour gérer la stack.

Ici la limite est à f78fb000  (on commence la stack à à l’adresse f78f8000 ) : Stack Init f78fb000 Current f78f9150 Base f78fb000 Limit f78f8000

Le dernier appel a été fait à l’adresse f78f81b8 ;  par conséquent l’appel d’après aurait utiliser de la mémoire et dépasser ainsi la limite du f78f8000 d’où le stack overflow et le crash.

Voici les détails de consommation de la stack au moment du Stop:

  Module      Stack Usage Percentage

fltMgr                280          2

volsnap               584          5

Ntfs                 4844        42

iscsiprt              188          2

NDIS                  140          1

msiscsi               276          2

q57xp32               144          1

CLASSPNP              104          1

mfetdik               144          1

hal                    44          0

dmio                  328          3

tcpip                 600          5

mpio                  356          3

PartMgr                16          0

mfehidk               660          6

nt                   1988        17

df2k                  848          7

Nous constatons que Ntfs utilise 42% de celle-ci ce qui est beaucoup. Maintenant si l’on regarde attentivement la stack nous allons constater que c’est le driver df2k.sys qui est réentrant dans le file system.

0: kd> kv 100

ChildEBP RetAddr  Args to Child             

00000000 bae30bf7 00000000 00000000 00000000 nt!_KiTrap08+0x75

WARNING: Stack unwind information not available. Following frames may be wrong.

f78f81b8 bae29c53 89756000 89fc3f30 8975bf54 q57xp32+0x9bf7

f78f8200 bae29edb 854b8310 f78f8278 f78f8248 q57xp32+0x2c53

f78f8210 bae2a199 02756000 878032e0 897ef950 q57xp32+0x2edb

f78f8248 f76ee804 00000001 f78f8278 00000000 q57xp32+0x3199

f78f8260 80a7a24f 897ef850 00000000 86e62a20 NDIS!ndisMProcessSGList+0x90

f78f828c f76ee6fe 86e62a20 897ef850 878032c0 hal!HalBuildScatterGatherList+0x1c7

f78f82e4 f76d249d 8a3d5008 854b8310 862fe230 NDIS!ndisMAllocSGList+0xd9

f78f8300 ba782f37 89e90290 854b8310 89d16c48 NDIS!ndisMSendX+0x1a0

f78f8328 ba78223a 8a3d5008 854b8310 8638eae8 tcpip!IPRcvComplete+0x12d3

f78f8350 ba782622 8638ea02 f78f8402 00000001 tcpip!IPRcvComplete+0x5d6

f78f848c ba783c01 ba7bbbb8 862fe2a4 862fe230 tcpip!IPRcvComplete+0x9be

f78f84fc ba783da0 f3b3f555 00000002 875d30c0 tcpip!IPRcvComplete+0x1f9d

f78f8524 ba784478 00000001 00000000 00000002 tcpip!IPRcvComplete+0x213c

f78f8558 bab209ac 875d3008 89443364 89d2d540 tcpip!IPRcvComplete+0x2814

f78f857c bab29a46 89e8e000 89429058 89e8e000 msiscsi+0x99ac

f78f8624 bab2c101 01429058 84f25502 84f2552c msiscsi+0x12a46

f78f8644 bab1a435 808a5180 84f25502 00000000 msiscsi+0x15101

f78f866c bab036ca 8a02b65c 89e8e000 f78f8698 msiscsi+0x3435

f78f867c bab03afc 897c31a0 84f2552c 884b7d28 iscsiprt!RaCallMiniportStartIo+0x1e

f78f8698 bab0c182 84f2552c 870a48a0 89d17e18 iscsiprt!RaidAdapterPostScatterGatherExecute+0x5e

f78f86b8 bab07823 00000000 00000001 00000000 iscsiprt!RaUnitStartIo+0xc4

f78f86d8 bab0b575 89d17e18 014b7d28 00000000 iscsiprt!RaidStartIoPacket+0x49

f78f86fc bab0c8a6 89d17d30 884b7d28 84c6d270 iscsiprt!RaidUnitSubmitRequest+0x63

f78f8718 bab06844 89d17d30 884b7d28 f78f873c iscsiprt!RaUnitScsiIrp+0x92

f78f8728 8083f9d0 89d17c78 884b7d28 89e8caa0 iscsiprt!RaDriverScsiIrp+0x2a

f78f873c f7409440 884b7d28 884b7dfc 884b7d28 nt!IofCallDriver+0x45

f78f8764 f74094e0 89cfba88 884b7d28 884b7d28 mpio!MPIOReadWrite+0x19e

f78f8830 f7409b34 89cfba88 84c6d1f0 884b7dd8 mpio!MPIOPdoHandleRequest+0x76

f78f8848 f7408945 89cfbb40 884b7d28 884b7d28 mpio!MPIOPdoInternalDeviceControl+0x3c

f78f8870 f740916f 89cfba88 89cfbd78 01000000 mpio!MPIOPdoCommonDeviceControl+0x1fb

f78f8890 f74062ef 89cfba88 884b7d28 f78f88b4 mpio!MPIOPdoDispatch+0x8f

f78f88a0 8083f9d0 89cfba88 884b7d28 84f25480 mpio!MPIOGlobalDispatch+0x19

f78f88b4 f7139a20 84f25480 68d0e000 f78f88f8 nt!IofCallDriver+0x45

f78f88c4 f7139635 84f25480 89419b70 85a52e2c CLASSPNP!SubmitTransferPacket+0xbb

f78f88f8 f7139712 00000000 00001000 85a52e50 CLASSPNP!ServiceTransferRequest+0x1e4

f78f891c 8083f9d0 89419ab8 00000000 8ab96b38 CLASSPNP!ClassReadWrite+0x159

f78f8930 f74d80cf 8756c3a8 85a52e50 f78f8954 nt!IofCallDriver+0x45

f78f8940 8083f9d0 893e7780 85a52cc0 85a52cc0 PartMgr+0x10cf

f78f8954 f73b4802 890bd008 8756c3a8 89595d08 nt!IofCallDriver+0x45

f78f899c f73cdfa3 8756c3a8 010bd008 04000000 dmio!voldiskiostart+0x482

f78f89ec f73bf8dc 8756c3a8 f78f8a44 f78f8a38 dmio!vol_subdisksio_start+0x107

f78f8a5c f73b5e2c 8712c408 00000001 00000001 dmio!volkiostart+0x32c

f78f8a88 f73b85e2 88dc1a60 85a52cc0 8ab50418 dmio!volrdwr+0xa0

f78f8a9c 8083f9d0 88dc1a60 85a52cc0 85a52e98 dmio!volread+0x58

f78f8ab0 f73899c4 8ab2d248 88db7af0 88d246d0 nt!IofCallDriver+0x45

f78f8ac8 8083f9d0 88d246d0 85a52cc0 85a52cc0 volsnap+0x19c4

f78f8adc f70d9881 88db7a38 88db7af0 88ba5c98 nt!IofCallDriver+0x45

f78f8b34 f70dae17 88db7a38 85a52cc0 85a52cc0 df2k+0x6881

f78f8b5c f701d0ce f78f8e40 f78f8d40 f701c702 df2k+0x7e17

f78f8b68 f701c702 f78f8e40 88db7a38 9c09a000 Ntfs!NtfsSingleAsync+0x91

f78f8d40 f701a75e f78f8e40 85a52cc0 88ba5c98 Ntfs!NtfsNonCachedIo+0x2db

f78f8e2c f701d8de f78f8e40 85a52cc0 00000001 Ntfs!NtfsCommonRead+0xaf5

f78f8fd8 8083f9d0 88be6718 85a52cc0 85a52cc0 Ntfs!NtfsFsdRead+0x113

f78f8fec f7117b43 88f2aae8 85a52cc0 88eeb008 nt!IofCallDriver+0x45

f78f9010 f7117d03 f78f9030 88f2aae8 00000000 fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b

f78f9048 8083f9d0 88f2aae8 85a52cc0 88db7af0 fltMgr!FltpDispatch+0x11f

f78f905c f70d8ab1 89944588 89944640 88fcd5c0 nt!IofCallDriver+0x45

f78f9100 f70dae17 89944588 85a52cc0 85a52ebc df2k+0x5ab1

f78f9128 ba9efa40 88d1da08 89705218 88bed008 df2k+0x7e17

f78f913c 8083f9d0 88aacf10 85a52cc0 85a52cc0 SYMEVENT!SYMEvent_AllocVMData+0x5f00

f78f9150 f7117d36 0010e000 8a0d1768 00000000 nt!IofCallDriver+0x45

f78f917c 8083f9d0 88d1da08 85a52cc0 85a52cc0 fltMgr!FltpDispatch+0x152

f78f9190 8082f0de 83e86308 8ab868d0 83e862f8 nt!IofCallDriver+0x45

f78f91a8 8082f17c 88f04f0c 83e86330 83e86310 nt!IoPageRead+0x109

f78f922c 80849ce5 00000001 c16ce000 c0305b38 nt!MiDispatchFault+0xd2a

f78f9288 8082fd4f 00000000 c16ce000 00000000 nt!MmAccessFault+0x64a

f78f92b8 80845b53 c16ce000 00000000 f78f93e4 nt!MmCheckCachedPageState+0x48e

f78f9300 80845d5a 88ba5b60 f78f9340 00001000 nt!CcMapAndRead+0x93

f78f9394 8092f599 88f04f90 f78f93d4 00001000 nt!CcPinFileData+0x24a

f78f9408 f7054d25 88f04f90 f78f9440 00001000 nt!CcPinRead+0xc4

f78f9430 f704842b 84f7a168 88ba5c98 0010e000 Ntfs!NtfsPinStream+0x76

f78f945c f7049751 84f7a168 88be67f8 00870000 Ntfs!NtfsMapOrPinPageInBitmap+0x9d

f78f94d8 f704851f 84f7a168 88be67f8 0087312e Ntfs!NtfsAllocateBitmapRun+0x4b

f78f9614 f7040136 84f7a168 88be67f8 87342a00 Ntfs!NtfsAllocateClusters+0x9fd

f78f96d4 f7047e53 84f7a168 87342a00 00000020 Ntfs!NtfsAllocateAttribute+0x156

f78f9774 f704835c 84f7a168 d6650468 00000020 Ntfs!NtfsCreateNonresidentWithValue+0xde

f78f9874 f706e627 84f7a168 d6650468 d1911898 Ntfs!NtfsConvertToNonresident+0x2ec

f78f99cc f7076cc4 84f7a168 d6650468 00000240 Ntfs!NtfsChangeAttributeValue+0x467

f78f9ab8 f7071d04 84f7a168 d6650468 000fe6ad Ntfs!NtfsAddToAttributeList+0x177

f78f9ca0 f7047a50 84f7a168 d6650530 f78f9cd0 Ntfs!NtfsAddAttributeAllocation+0xf71

f78f9d64 f70845ef 84f7a168 8523cc68 d6650530 Ntfs!NtfsAddAllocation+0x397

f78f9e74 f7041c94 84f7a168 8523cc68 859c0370 Ntfs!NtfsSetAllocationInfo+0x3dd

f78f9ee0 f701d2fb 84f7a168 859c0370 00000000 Ntfs!NtfsCommonSetInformation+0x48c

f78f9f48 8083f9d0 88be6718 859c0370 859c0370 Ntfs!NtfsFsdSetInformation+0xa3

f78f9f5c f7117b43 88f2aae8 859c0370 88eeb008 nt!IofCallDriver+0x45

f78f9f80 f7117d03 f78f9fa0 88f2aae8 00000000 fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b

f78f9fb8 8083f9d0 88f2aae8 859c0370 88db7af0 fltMgr!FltpDispatch+0x11f

f78f9fcc f70d8ab1 89944588 89944640 f78fa0e8 nt!IofCallDriver+0x45

f78fa070 f70dae17 89944588 859c0370 859c056c df2k+0x5ab1

f78fa098 ba9ef7b1 859c056c 859c0590 f78fa0e8 df2k+0x7e17

f78fa0b0 ba9f8d68 89944588 00000000 f78fa0e8 SYMEVENT!SYMEvent_AllocVMData+0x5c71

f78fa0cc ba9ef91b f78fa0e8 8082b0b9 ba9ef9e3 SYMEVENT!EventObjectCreate+0xba8

f78fa10c 8083f9d0 88aacf10 859c0370 859c0370 SYMEVENT!SYMEvent_AllocVMData+0x5ddb

f78fa120 f7117b43 88d1da08 859c0370 88bed008 nt!IofCallDriver+0x45

f78fa144 f7117d03 f78fa164 88d1da08 00000000 fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b

f78fa17c 8083f9d0 88d1da08 859c0370 859c0370 fltMgr!FltpDispatch+0x11f

f78fa190 8098911f 85391008 84c497a0 f78fa434 nt!IofCallDriver+0x45

f78fa1c8 f707e07c 0123cc68 00000013 85391018 nt!IoSetInformation+0x1c2

f78fa1f4 f706c7b7 84c497a0 85391008 d66506b8 Ntfs!NtfsCompleteLargeAllocation+0x40

f78fa3f4 f70531e5 84c497a0 85391008 f78fa434 Ntfs!NtfsCommonCreate+0x1472

f78fa4f8 8083f9d0 88be6718 85391008 85391008 Ntfs!NtfsFsdCreate+0x17d

f78fa50c f7117b43 00000000 85391008 85391198 nt!IofCallDriver+0x45

f78fa530 f71255af f78fa550 88f2aae8 00000000 fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b

f78fa56c 8083f9d0 88f2aae8 85391008 853911d8 fltMgr!FltpCreate+0x23b

f78fa580 f70da51c 8081fd79 899446b0 899446f4 nt!IofCallDriver+0x45

f78fa5b0 f70d942b 899446b0 85391008 00000000 df2k+0x751c

f78fa5e4 f70d8fed 89944640 85391008 89944588 df2k+0x642b

f78fa690 f70dae17 89944588 85391008 853911e0 df2k+0x5fed

f78fa6b8 ba9ef8a1 853911e0 85391204 f78fa718 df2k+0x7e17

f78fa6e0 ba9f8d58 89944588 00000000 f78fa718 SYMEVENT!SYMEvent_AllocVMData+0x5d61

f78fa6fc ba9ef91b f78fa718 8082b0b9 ba9ef9e3 SYMEVENT!EventObjectCreate+0xb98

f78fa73c 8083f9d0 88aacf10 85391008 85391008 SYMEVENT!SYMEvent_AllocVMData+0x5ddb

f78fa750 f7117b43 00000000 85391008 85391204 nt!IofCallDriver+0x45

f78fa774 f71255af f78fa794 88d1da08 00000000 fltMgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x20b

f78fa7b0 8083f9d0 88d1da08 85391008 85391008 fltMgr!FltpCreate+0x23b

f78fa7c4 8092e269 f78fa96c 88dc1a48 00000000 nt!IofCallDriver+0x45

f78fa8ac 80936caa 88dc1a60 00000000 88e62860 nt!IopParseDevice+0xa35

f78fa92c 80936aa5 00000000 f78fa96c 00000240 nt!ObpLookupObjectName+0x5a9

f78fa980 80936f27 00000000 00000000 00000100 nt!ObOpenObjectByName+0xea

f78fa9fc 80936ff8 8a2f22e4 0012019f f78fab7c nt!IopCreateFile+0x447

f78faa58 8092ed98 8a2f22e4 0012019f f78fab7c nt!IoCreateFile+0xa3

f78faa98 80834d3f 8a2f22e4 0012019f f78fab7c nt!NtCreateFile+0x30

f78faa98 8083c1ec 8a2f22e4 0012019f f78fab7c nt!KiFastCallEntry+0xfc

f78fab3c f7396acb 8a2f22e4 0012019f f78fab7c nt!ZwCreateFile+0x11

f78fabc4 f739c6f7 8a2f22d0 00000001 f78fabec volsnap+0xeacb

f78fabf8 f73a5d5d 86a966e0 12c00000 00000000 volsnap+0x146f7

f78fad50 f73945e5 8aa020d8 851a5798 8ab868d0 volsnap+0x1dd5d

f78fad6c 809180a0 875603d0 88eb2ab8 808b70dc volsnap+0xc5e5

f78fad80 8083f72e 875603d0 00000000 8ab868d0 nt!IopProcessWorkItem+0x13

f78fadac 8092ccff 875603d0 00000000 00000000 nt!ExpWorkerThread+0xeb

f78faddc 80841a96 8083f671 00000001 00000000 nt!PspSystemThreadStartup+0x2e

00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

La stack contient aussi plusieurs occurrences du module SYMEVENT qui est connu pour causer des problèmes de stack overflow

La solution au problème rencontré passera par:

- Désinstallation ou mise à jour du composant Df2K.sys

- Suivi des recommandations de Symantec pour la partie Symevent : http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2002071208532048?Open&src=w

 Mounia

Windows Core Technical Lead

Suite au succès rencontré le 5 Mai dernier, la journée technique d’expertise thématique (JTET) consacrée à Windows Server 2008, “Windows Server 2008 - Technologie et Méthodologie : Les clés de la réussite”, sera rejouée le 20 Janvier 2009 à nos clients Premier.

J’aurais à nouveau le plaisir d’y participer et de présenter les technologies Windows Server avec mes camarades Arnaud Lheureux, Julien Peyridieux et Jean Ragot.

 

D’un existant sous Windows 2000 (serveurs, AD, Exchange, client, Outlook) les trois intervenants upgraderont vers les toutes dernières versions de Windows Server, de Windows Vista, d’Exchange avec les tous derniers outils de déploiement Microsoft (MDT 2008, Microsoft Deployment Toolkit), et mettront en œuvre la quasi-totalité des nouvelles technologies présentes dans ces produits en suivant la méthodologie MOF, ce dont le spécialiste méthodologies s’assurera au fil de nos opérations.

D’une plateforme basique nous aboutirons à une plateforme représentant un condensé du savoir-faire Microsoft en matière d’architecture serveurs, le tout en suivant les principes et les règles MOF. Une plateforme transfigurée en quelques heures, des solutions neuves et efficaces mises à la disposition des utilisateurs, en bref, la vie d’une infrastructure IT en une journée.

Agenda :

• Introduction à la situation : un existant, une cible, les principes MOF que nous suivons
• Chaîne des composants, cartographie de l’existant
• Upgrade Active Directory de Windows Server 2000 à Windows Server 2008 et déploiement automatisé
• Gestion de changement (changement standard, changement majeur)
• Mise à jour vers Exchange 2007 SP1
• Déploiement automatisé de cluster
• Migration client de Windows XP vers Windows Vista SP1 avec préservation des données/profils utilisateurs
• Déploiement automatisé de RODC avec IFM sur Server Core
• Mise en place de l’isolation de domaine
• Déploiement de NAP
• Gestion du niveau de service
• Mise en place de QoS
• Exploitation des nouveautés des stratégies de groupes
• Déploiement des solutions Terminal Services et mise à disposition des services d’accès distants aux applications internes
• Déploiement du 802.1x/SSO
• Exploitation des nouveautés Active Directory
• Mise en place des Fine-Grained Password Policy
• Gestion d’incidents
• CMDB
• Hyper-V
• Mise en place du remote access
• Et bien d’autres choses encore… Le tout à la façon MS IT, à savoir en suivant la méthodologie MOF

 

Comme indiqué plus haut, cette journée est réservée aux clients Premier. Pour ceux d’entre vous qui disposent d’un tel contrat, contactez votre TAM pour obtenir les modalités d’inscriptions.

Je vous donne rendez-vous pour cette journée hyper-intensive ! Ce sera l’occasion pour vous d’appréhender les problématiques techniques qui nous mobilisent tous les jours et la façon de les anticiper.

 

Guillaume

Windows Core Support Escalation Engineer

Définition du problème

 

Aléatoirement, lors de connexions RDP sur un serveur TS, le phénomène suivant se produit : après son ouverture de session, un utilisateur se retrouve uniquement avec le fond d’écran du bureau sans aucun icônes.

 

Action

 

Lors de l’apparition du problème, nous avons forcé la génération d’un memory dump du serveur manuellement:

KB254649  Overview of memory dump file options for Windows Server 2003, Windows XP, and Windows 2000

http://support.microsoft.com/default.aspx?scid=kb;EN-US;254649

KB244139  Windows feature lets you generate a memory dump file by using the keyboard

http://support.microsoft.com/default.aspx?scid=kb;EN-US;244139

 

Analyse du dump

 

Pour le téléchargement et l’installation de Windbg, voir mon précédent post « Debugger un 100% CPU du spooler ». Concernant les commandes utilisées ici, vous pouvez trouver plus d’informations dans l’aide de Windbg.

Dans l’analyse du dump, nous pouvons voir des threads en attente d’une « critical section » (voir définition ici http://fr.wikipedia.org/wiki/Section_critique) .

Voici un exemple de thread en attente d’une « critical section » :

 

0:018> ~11s <- Cette commande permet de ce placer dans le contexte d’un thread en particulier, ici le thread 11 du process spoolsv.exe

eax=00002f9c ebx=00000000 ecx=00000187 edx=00002f9c esi=7c8877a0 edi=00000000

eip=7c8285ec esp=01b2f3bc ebp=01b2f3f8 iopl=0         nv up ei pl zr na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246

ntdll!KiFastSystemCallRet:

7c8285ec c3              ret

0:011> kv <- permet d’afficher la pile du thread

ChildEBP RetAddr  Args to Child             

01b2f3b8 7c827d0b 7c83d236 00000124 00000000 ntdll!KiFastSystemCallRet

01b2f3bc 7c83d236 00000124 00000000 00000000 ntdll!NtWaitForSingleObject+0xc

01b2f3f8 7c83d281 00000124 00000004 00000001 ntdll!RtlpWaitOnCriticalSection+0x1a3

01b2f418 7c82d243 7c8877a0 00000000 000000e9 ntdll!RtlEnterCriticalSection+0xa8

01b2f44c 7c834029 00000001 00000000 01b2f488 ntdll!LdrLockLoaderLock+0xe4 

01b2f6bc 77e41bf3 027125c8 01b2f708 01b2f6e8 ntdll!LdrLoadDll+0xc9 

01b2f724 77e5c70b 72451460 00000000 00000000 kernel32!LoadLibraryExW+0x1b2 

01b2f738 72451310 72451460 01b2fc90 000000e9 kernel32!LoadLibraryW+0x11 

01b2f750 724516f9 01b2f75c 01bf8a50 00000780 usbmon!LoadSetupApiDll+0x1f 

01b2f778 72451687 72455068 01b2f794 01b2fca0 usbmon!BuildPortList+0x11 

01b2f79c 76136227 00000000 00000002 00000000 usbmon!DynaMon_EnumPorts+0x64 

01b2f7bc 7615c9ce 00aded40 00000000 00000002 localspl!DpEnumPorts+0x1d 

01b2f808 7615d2fb 00000000 00000002 00000000 localspl!SplEnumPorts+0xb8 

01b2f834 740706e4 00000000 00000002 00000000 localspl!LocalEnumPorts+0x2f 

01b2f874 01008d1e 00000000 00000002 00000000 spoolss!EnumPortsW+0x6d 

01b2f8a8 01006d07 00000000 00000002 00000000 spoolsv!YEnumPorts+0x8b

01b2f8cc 77c80193 00000000 00000002 00000000 spoolsv!RpcEnumPorts+0x1e

01b2f8f8 77ce33e1 01006ce9 01b2fae0 00000006 rpcrt4!Invoke+0x30

01b2fcf8 77ce35c4 00000000 00000000 000eb3b4 rpcrt4!NdrStubCall2+0x299 

01b2fd14 77c7ff7a 000eb3b4 000d3888 000eb3b4 rpcrt4!NdrServerCall2+0x19 

RtlpWaitOnCriticalSection indique que ce thread est en attente sur une « critical section ».

 

On fait un KP pour avoir les paramètres des appels de fonctions :

 

0:011> kP

ChildEBP RetAddr 

01b2f3b8 7c827d0b ntdll!KiFastSystemCallRet(void)

01b2f3bc 7c83d236 ntdll!NtWaitForSingleObject(void)+0xc

01b2f3f8 7c83d281 ntdll!RtlpWaitOnCriticalSection(

                  struct _RTL_CRITICAL_SECTION * CriticalSection = 0x00000124,

                  long Increment = 4)+0x1a3

01b2f418 7c82d243 ntdll!RtlEnterCriticalSection(

                  struct _RTL_CRITICAL_SECTION * CriticalSection = 0x7c8877a0)+0xa8

01b2f44c 7c834029 ntdll!LdrLockLoaderLock(

                  unsigned long Flags = 1,

                  unsigned long * Disposition = 0x00000000,

                  void ** Cookie = 0x01b2f488)+0xe4

01b2f6bc 77e41bf3 ntdll!LdrLoadDll(

                  unsigned short * DllPath = 0x027125c8,

                  unsigned long * DllCharacteristics = 0x01b2f708,

                  struct _UNICODE_STRING * DllName = 0x01b2f6e8 "setupapi",

                  void ** DllHandle = 0x01b2f704)+0xc9 [

01b2f724 77e5c70b kernel32!LoadLibraryExW(

                  unsigned short * lpwLibFileName = 0x72451460,

                  void * hFile = 0x00000000,

                  unsigned long dwFlags = 0)+0x1b2

01b2f738 72451310 kernel32!LoadLibraryW(

                  unsigned short * lpwLibFileName = 0x72451460)+0x11

01b2f750 724516f9 usbmon!LoadSetupApiDll(

                  struct _SETUPAPI_INFO * pSetupInfo = 0x01b2f75c)+0x1f

01b2f778 72451687 usbmon!BuildPortList(

                  struct DynaMon_Monitor_Info_Struct * pMonitorInfo = 0x72455068,

                  struct Port_Update_Struct ** ppPortUpdateList = 0x01b2f794)+0x11

01b2f79c 76136227 usbmon!DynaMon_EnumPorts(

                  unsigned short * pszName = 0x00000000,

                  unsigned long dwLevel = 2,

                  unsigned char * pPorts = 0x00000000 "",

                  unsigned long cbBuf = 0,

                  unsigned long * pcbNeeded = 0x01b2fc90,

                  unsigned long * pcReturned = 0x01b2fca0)+0x64

01b2f7bc 7615c9ce localspl!DpEnumPorts(

                  void * hMonitor = 0x00aded40,

                  unsigned short * pName = 0x00000000,

                  unsigned long Level = 2,

                  unsigned char * pPorts = 0x00000000 "",

                  unsigned long cbBuf = 0,

                  unsigned long * pcbNeeded = 0x01b2fc90,

                  unsigned long * pcReturned = 0x01b2fca0)+0x1d

01b2f808 7615d2fb localspl!SplEnumPorts(

                  unsigned short * pName = 0x00000000,

                  unsigned long Level = 2,

                  unsigned char * pPorts = 0x00000000 "",

                  unsigned long cbBuf = 0,

                  unsigned long * pcbNeeded = 0x01b2fc90,

                  unsigned long * pcReturned = 0x01b2fca0,

                  struct _INISPOOLER * pIniSpooler = 0x00a956a8)+0xb8

01b2f834 740706e4 localspl!LocalEnumPorts(

                  unsigned short * pName = 0x00000000,

                  unsigned long Level = 2,

                  unsigned char * pPorts = 0x00000000 "",

                  unsigned long cbBuf = 0,

                  unsigned long * pcbNeeded = 0x01b2fc90,

                  unsigned long * pcReturned = 0x01b2fca0)+0x2f

01b2f874 01008d1e spoolss!EnumPortsW(

                  unsigned short * pName = 0x00000000,

                  unsigned long Level = 2,

                  unsigned char * pPort = 0x00000000 "",

                  unsigned long cbBuf = 0,

                  unsigned long * pcbNeeded = 0x01b2fc90,

                  unsigned long * pcReturned = 0x01b2fca0)+0x6d

01b2f8a8 01006d07 spoolsv!YEnumPorts(

                  unsigned short * pName = 0x00000000,

                  unsigned long Level = 2,

                  unsigned char * pPort = 0x00000000 "",

                  unsigned long cbBuf = 0,

                  unsigned long * pcbNeeded = 0x01b2fc90,

                  unsigned long * pcReturned = 0x01b2fca0,

                  Call_Route Route = RPC_CALL (1))+0x8b

01b2f8cc 77c80193 spoolsv!RpcEnumPorts(

                  unsigned short * pName = 0x00000000,

                  unsigned long Level = 2,

                  unsigned char * pPort = 0x00000000 "",

                  unsigned long cbBuf = 0,

                  unsigned long * pcbNeeded = 0x01b2fc90,

                  unsigned long * pcReturned = 0x01b2fca0)+0x1e [

01b2f8f8 77ce33e1 rpcrt4!Invoke(void)+0x30

01b2fcf8 77ce35c4 rpcrt4!NdrStubCall2(

                  struct IRpcStubBuffer * pThis = 0x00000000,

                  struct IRpcChannelBuffer * pChannel = 0x00000000,

                  struct _RPC_MESSAGE * pRpcMsg = 0x000eb3b4,

                  unsigned long * pdwStubPhase = 0x01b2fd10)+0x299

01b2fd14 77c7ff7a rpcrt4!NdrServerCall2(

                  struct _RPC_MESSAGE * pRpcMsg = 0x000eb3b4)+0x19

 

Ceci nous montre les paramètres des appels de fonctions et nous montre que ce thread est bloqué car il attend la « critical section » 0x7c8877a0.

 

0:011> dt _RTL_CRITICAL_SECTION 0x7c8877a0

spoolsv!_RTL_CRITICAL_SECTION

   +0x000 DebugInfo        : 0x7c8877c0 _RTL_CRITICAL_SECTION_DEBUG

   +0x004 LockCount        : -38

   +0x008 RecursionCount   : 1

   +0x00c OwningThread     : 0x000046ac

   +0x010 LockSemaphore    : 0x00000124

   +0x014 SpinCount        : 0

 

Cette critical section est détenue par le thread 0x000046ac.

 

Voyons à quel numéro de thread cela correspond :

 

0:011> !runaway <- permet d’afficher le temps consommé par chaque thread

User Mode Time

  Thread       Time

  11:4784      0 days 0:00:01.562

  13:46ac      0 days 0:00:00.890

  15:4ef8      0 days 0:00:00.406

  16:4f60      0 days 0:00:00.125

   3:680       0 days 0:00:00.093

  10:78c       0 days 0:00:00.031

  22:4dc8      0 days 0:00:00.000

  21:4e08      0 days 0:00:00.000

  20:3bf0      0 days 0:00:00.000

  19:4340      0 days 0:00:00.000

  18:4b80      0 days 0:00:00.000

  17:1e1c      0 days 0:00:00.000

  14:4b3c      0 days 0:00:00.000

  12:47f0      0 days 0:00:00.000

   9:724       0 days 0:00:00.000

   8:720       0 days 0:00:00.000

   7:71c       0 days 0:00:00.000

   6:718       0 days 0:00:00.000

   5:6c4       0 days 0:00:00.000

   4:68c       0 days 0:00:00.000

   2:57c       0 days 0:00:00.000

   1:570       0 days 0:00:00.000

   0:558       0 days 0:00:00.000

 

On se place dans le contexte du thread :

 

0:011> ~13s

eax=00000001 ebx=77792c30 ecx=0207f501 edx=00000000 esi=00000a60 edi=00000000

eip=7c8285ec esp=0207fd60 ebp=0207fdd0 iopl=0         nv up ei pl zr na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246

ntdll!KiFastSystemCallRet:

7c8285ec c3              ret

 

Puis on liste toute la stack :

 

0:013> kv

ChildEBP RetAddr  Args to Child             

0207fd5c 7c827d0b 77e61d1e 00000a60 00000000 ntdll!KiFastSystemCallRet

0207fd60 77e61d1e 00000a60 00000000 00000000 ntdll!NtWaitForSingleObject+0xc

0207fdd0 77e61c8d 00000a60 ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xac 

0207fde4 776f56f4 00000a60 ffffffff 77792cf0 kernel32!WaitForSingleObject+0x12 

0207fe00 7768dac2 00000a60 00000000 00000080 ole32!CDllHost::ClientCleanupFinish+0x2a 

0207fe2c 7768da32 00000000 0207fe7c 777966d4 ole32!DllHostProcessUninitialize+0x80 

0207fe4c 776bce20 00000000 00000000 02702988 ole32!ApartmentUninitialize+0xf8 

0207fe64 776bcdd2 0207fe7c 00000000 00000001 ole32!wCoUninitialize+0x7d

0207fe80 776e4de6 00000001 77670000 776bc793 ole32!CoUninitialize+0x65 

0207fe8c 776bc793 0207feb4 776bc732 77670000 ole32!DoThreadSpecificCleanup+0x63 

0207fe94 776bc732 77670000 00000003 00000000 ole32!ThreadNotification+0x37 

0207feb4 776bc6da 77670000 00000003 00000000 ole32!DllMain+0x194 

0207fed4 7c81a352 77670000 00000003 00000000 ole32!_DllMainCRTStartup+0x52 

0207fef4 7c819178 776bc692 77670000 00000003 ntdll!LdrpCallInitRoutine+0x14

0207ffa8 77e4f920 00000000 00000000 0207ffec ntdll!LdrShutdownThread+0xd2 

0207ffb8 77e6482e 00000000 00000000 00000000 kernel32!ExitThread+0x2f 

0207ffec 00000000 77c7b0f5 000bb338 00000000 kernel32!BaseThreadStart+0x39

 

On peu voir que ce thread est en attente avec un WaitForSingleObject.

 

On fait un kP pour avoir l’objet sur lequel ce thread est en attente :

 

0:013> kP

ChildEBP RetAddr 

0207fd5c 7c827d0b ntdll!KiFastSystemCallRet(void) [

0207fd60 77e61d1e ntdll!NtWaitForSingleObject(void)+0xc

0207fdd0 77e61c8d kernel32!WaitForSingleObjectEx(

                  void * hHandle = 0x00000a60,

                  unsigned long dwMilliseconds = 0xffffffff,

                  int bAlertable = 0)+0xac

0207fde4 776f56f4 kernel32!WaitForSingleObject(

                  void * hHandle = 0x00000a60,

                  unsigned long dwMilliseconds = 0xffffffff)+0x12

0207fe00 7768dac2 ole32!CDllHost::ClientCleanupFinish(

                  void * hEvent = 0x00000a60)+0x2a

0207fe2c 7768da32 ole32!DllHostProcessUninitialize(void)+0x80

0207fe4c 776bce20 ole32!ApartmentUninitialize(

                  int fHostThread = 0)+0xf8

0207fe64 776bcdd2 ole32!wCoUninitialize(

                  class COleTls * Tls = 0x0207fe7c,

                  int fHostThread = 0)+0x7d

0207fe80 776e4de6 ole32!CoUninitialize(void)+0x65

0207fe8c 776bc793 ole32!DoThreadSpecificCleanup(void)+0x63

0207fe94 776bc732 ole32!ThreadNotification(

                  struct HINSTANCE__ * hDll = 0x77670000,

                  unsigned long dwReason = 3,

                  void * lpvReserved = 0x00000000)+0x37

0207feb4 776bc6da ole32!DllMain(

                  void * hInstance = 0x77670000,

                  unsigned long dwReason = 3,

                  void * lpvReserved = 0x00000000)+0x194

0207fed4 7c81a352 ole32!_DllMainCRTStartup(

                  void * hDllHandle = 0x77670000,

                  unsigned long dwReason = 3,

                  void * lpreserved = 0x00000000)+0x52

0207fef4 7c819178 ntdll!LdrpCallInitRoutine(void)+0x14

0207ffa8 77e4f920 ntdll!LdrShutdownThread(void)+0xd2

0207ffb8 77e6482e kernel32!ExitThread(

                  unsigned long dwExitCode = 0)+0x2f

0207ffec 00000000 kernel32!BaseThreadStart(

                  <function> * lpStartAddress = 0x77c7b0f5,

void * lpParameter = 0x000bb338)+0x39

 

Puis on tape la commande suivante :

 

0:013> !handle 0x00000a60

Handle 00000a60

  Type            Event

 

Cet objet est un Event, donc ce thread attend qu’un Event soit signalé.

 

Regardons un peu plus loin dans la stack :

 

0:013> kv n (le “n” permet d’afficher les numéro de frame)

# ChildEBP RetAddr  Args to Child             

00 0207fd5c 7c827d0b 77e61d1e 00000a60 00000000 ntdll!KiFastSystemCallRet

01 0207fd60 77e61d1e 00000a60 00000000 00000000 ntdll!NtWaitForSingleObject+0xc

02 0207fdd0 77e61c8d 00000a60 ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xac 

03 0207fde4 776f56f4 00000a60 ffffffff 77792cf0 kernel32!WaitForSingleObject+0x12 

04 0207fe00 7768dac2 00000a60 00000000 00000080 ole32!CDllHost::ClientCleanupFinish+0x2a 

05 0207fe2c 7768da32 00000000 0207fe7c 777966d4 ole32!DllHostProcessUninitialize+0x80

06 0207fe4c 776bce20 00000000 00000000 02702988 ole32!ApartmentUninitialize+0xf8 

07 0207fe64 776bcdd2 0207fe7c 00000000 00000001 ole32!wCoUninitialize+0x7d 

08 0207fe80 776e4de6 00000001 77670000 776bc793 ole32!CoUninitialize+0x65 

09 0207fe8c 776bc793 0207feb4 776bc732 77670000 ole32!DoThreadSpecificCleanup+0x63 

0a 0207fe94 776bc732 77670000 00000003 00000000 ole32!ThreadNotification+0x37

0b 0207feb4 776bc6da 77670000 00000003 00000000 ole32!DllMain+0x194 

0c 0207fed4 7c81a352 77670000 00000003 00000000 ole32!_DllMainCRTStartup+0x52 

0d 0207fef4 7c819178 776bc692 77670000 00000003 ntdll!LdrpCallInitRoutine+0x14

0e 0207ffa8 77e4f920 00000000 00000000 0207ffec ntdll!LdrShutdownThread+0xd2 

0f 0207ffb8 77e6482e 00000000 00000000 00000000 kernel32!ExitThread+0x2f

10 0207ffec 00000000 77c7b0f5 000bb338 00000000 kernel32!BaseThreadStart+0x39

 

Nous pouvons voir que ce thread est en cours de fermeture (kernel32!ExitThread) et dans une phase de fermeture d’un thread nous notifions toutes les dlls du processus pour leurs indiquer que ce thread se termine et dans cette stack nous avons :

 

0b 0207feb4 776bc6da 77670000 00000003 00000000 ole32!DllMain+0x194 

0c 0207fed4 7c81a352 77670000 00000003 00000000 ole32!_DllMainCRTStartup+0x52

0d 0207fef4 7c819178 776bc692 77670000 00000003 ntdll!LdrpCallInitRoutine+0x14

0e 0207ffa8 77e4f920 00000000 00000000 0207ffec ntdll!LdrShutdownThread+0xd2

0f 0207ffb8 77e6482e 00000000 00000000 00000000 kernel32!ExitThread+0x2f 

 

On se met sur la frame 0c :

 

0:013> .frame 0c

0c 0207fed4 7c81a352 ole32!_DllMainCRTStartup+0x52

 

Puis on fait un DV pour afficher les paramètres :

 

0:013> dv

     hDllHandle = 0x77670000

   dwReason = 3

   lpreserved = 0x00000000

   retcode = 3

 

Regardons maintenant à quoi correspond ce « hDllHandle » :

 

0:013> !lmi 0x77670000

Loaded Module Info: [0x77670000]

         Module: ole32

   Base Address: 77670000

     Image Name: ole32.dll

   Machine Type: 332 (I386)

     Time Stamp: 45d70aa5 Sat Feb 17 15:01:09 2007

           Size: 139000

       CheckSum: 14357b

Characteristics: 210e  perf

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    22, 11a44c,  11984c RSDS - GUID: {DC8A079C-AE0B-4A0C-89EC-5A936EAF1F7F}

               Age: 2, Pdb: ole32.pdb

                CLSID     4, 11a448,  119848 [Data not mapped]

     Image Type: MEMORY   - Image read successfully from loaded memory.

    Symbol Type: PDB      - Symbols loaded successfully from symbol server.

                        Compiler: C++ - front end [13.10 bld 4035] - back end [13.10 bld 4035]

 

Nous voyons que dans la phase de shutdown on appelle OLE32 et nous somme en attente d’un Event.

 

En regardant les autres thread du spooler, nous pouvons voir un thread qui est dans une phase de  LdrUnloadDll (déchargement d’une dll). Mais ce thread est en attente sur une « critical section » qui est celle détenue par le thread précédent :

 

0:013> ~18s

eax=77ec1944 ebx=00000000 ecx=77e424de edx=03311b00 esi=7c8877a0 edi=00000000

eip=7c8285ec esp=032cfcb8 ebp=032cfcf4 iopl=0         nv up ei pl zr na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246

ntdll!KiFastSystemCallRet:

7c8285ec c3              ret

0:018> kv

ChildEBP RetAddr  Args to Child             

032cfcb4 7c827d0b 7c83d236 00000124 00000000 ntdll!KiFastSystemCallRet

032cfcb8 7c83d236 00000124 00000000 00000000 ntdll!NtWaitForSingleObject+0xc

032cfcf4 7c83d281 00000124 00000004 00000000 ntdll!RtlpWaitOnCriticalSection+0x1a3 

032cfd14 7c839844 7c8877a0 032cfe70 032cfeac ntdll!RtlEnterCriticalSection+0xa8

032cfe1c 77e6b1bb 02100000 032cfeac 032cfedc ntdll!LdrUnloadDll+0x35

032cfe30 77691d0f 02100000 032cff04 77691d23 kernel32!FreeLibrary+0x41 

032cfe3c 77691d23 032cfeb8 777965b0 00000000 ole32!CClassCache::CDllPathEntry::CFinishObject::Finish+0x2f

032cfe50 77691afe 77671af0 00000000 00000000 ole32!CClassCache::CFinishComposite::Finish+0x1d 

032cff04 7769182a 02702bd8 00000080 776bc944 ole32!CClassCache::CleanUpDllsForApartment+0x1d0 

032cff30 7769174c 00000000 032cff84 777966d4 ole32!FinishShutdown+0xd7

032cff50 776bce20 00000001 00007530 77792c30 ole32!ApartmentUninitialize+0x94

032cff68 776f5797 032cff84 00000001 77e61c96 ole32!wCoUninitialize+0x7d

032cff88 7768f2a2 032cffac 776bbab4 77792c30 ole32!CDllHost::WorkerThread+0xdd

032cff90 776bbab4 77792c30 00000000 0270a1c0 ole32!DLLHostThreadEntry+0xd

032cffac 776b1704 00000000 032cffec 77e64829 ole32!CRpcThread::WorkerLoop+0x26

032cffb8 77e64829 0270a1c0 00000000 00000000 ole32!CRpcThreadCache::RpcWorkerThreadEntry+0x20 

032cffec 00000000 776b16e4 0270a1c0 00000000 kernel32!BaseThreadStart+0x34

 

Regardons quelle DLL ce thread essaie de décharger :

 

0:018> kP

ChildEBP RetAddr 

032cfcb4 7c827d0b ntdll!KiFastSystemCallRet(void)

032cfcb8 7c83d236 ntdll!NtWaitForSingleObject(void)+0xc

032cfcf4 7c83d281 ntdll!RtlpWaitOnCriticalSection(

                  struct _RTL_CRITICAL_SECTION * CriticalSection = 0x00000124,

                  long Increment = 4)+0x1a3

032cfd14 7c839844 ntdll!RtlEnterCriticalSection(

                  struct _RTL_CRITICAL_SECTION * CriticalSection = 0x7c8877a0)+0xa8

032cfe1c 77e6b1bb ntdll!LdrUnloadDll(

                  void * DllHandle = 0x02100000)+0x35

032cfe30 77691d0f kernel32!FreeLibrary(

                  struct HINSTANCE__ * hLibModule = 0x02100000)+0x41

032cfe3c 77691d23 ole32!CClassCache::CDllPathEntry::CFinishObject::Finish(void)+0x2f

032cfe50 77691afe ole32!CClassCache::CFinishComposite::Finish(void)+0x1d

032cff04 7769182a ole32!CClassCache::CleanUpDllsForApartment(void)+0x1d0

032cff30 7769174c ole32!FinishShutdown(void)+0xd7

032cff50 776bce20 ole32!ApartmentUninitialize(

                  int fHostThread = 1)+0x94

032cff68 776f5797 ole32!wCoUninitialize(

                  class COleTls * Tls = 0x032cff84,

                  int fHostThread = 1)+0x7d

032cff88 7768f2a2 ole32!CDllHost::WorkerThread(void)+0xdd

032cff90 776bbab4 ole32!DLLHostThreadEntry(

                  void * param = 0x77792c30)+0xd [

032cffac 776b1704 ole32!CRpcThread::WorkerLoop(void)+0x26

032cffb8 77e64829 ole32!CRpcThreadCache::RpcWorkerThreadEntry(

                  void * param = 0x0270a1c0)+0x20

032cffec 00000000 kernel32!BaseThreadStart(

                  <function> * lpStartAddress = 0x776b16e4,

                  void * lpParameter = 0x0270a1c0)+0x34

0:018> !lmi 0x02100000

Loaded Module Info: [0x02100000]

         Module: HPBOID

   Base Address: 02100000

     Image Name: HPBOID.DLL

   Machine Type: 332 (I386)

     Time Stamp: 45c30dad Fri Feb 02 11:08:45 2007

           Size: 9000

       CheckSum: e266

Characteristics: 210e 

Debug Data Dirs: Type  Size     VA  Pointer

             CODEVIEW    54,  1458,     858 RSDS - GUID: {6D0A74B4- DFB-4467-BA2A-27942C80B5FC}

    Image Type: MEMORY   - Image read successfully from loaded memory.

    Symbol Type: EXPORT   - PDB not found

Load Report: export symbols

 

Conclusion

 

Ici le problème semble lié au module HPBOID.

 

Résolution

 

Nous avons dans un premier temps renommé ce composant  afin de vérifier :

1. Si cela permettait de résoudre le problème (ce fût le cas)

2. De s’assurer que cela n’avait pas d’impact sur le bon fonctionnement des imprimantes.

 

Ensuite, il a fallut contacter l’éditeur de ce composant afin soit de le désinstaller sans impacter les imprimantes ou de se procurer une version mise à jour corrigeant ce problème.

 

Bon réveillon et bonne année.

Philippe

Windows Core Support Escalation Engineer

Voici une compilation des articles techniques concernant Hyper-V. La liste n’est pas exhaustive car elle n’inclue que les fiches concernant la version RTM et les problèmes et informations liés directement à Hyper-V, et j’ai pu en rater quelques unes...

Les titres sont en anglais (compréhension oblige) mais les liens dirigent vers la page traduite automatiquement en Français (je recommande tout de même de lire les articles en Anglais pour assurer une lecture non biaisée !).

A noter que certains articles sont en cours d’écriture, dont la fiche KB959962 (Hyper-V writer is required for backing up Hyper-V VMs with DPM) qui est prévue pour Janvier 2009.

 

Bonne lecture !

 

Supportabilité

KB897615 - Support policy for Microsoft software running in non-Microsoft hardware virtualization software

KB951041 - Supported paths for upgrading from Windows Server 2003 to Windows Server 2008

KB954958 - Guest operating systems that are supported on a Hyper-V virtual machine

KB957006 - Microsoft server software and supported virtualization environments

KB957054 - Support for Microsoft Dynamics CRM 4.0 on a computer that is running Windows Server 2008 Hyper-V

KB956893 - Support policy for Microsoft SQL Server products that are running in a hardware virtualization environment

KB842301 - Microsoft BizTalk Server supportability on a virtual machine

KB320220 - Microsoft support policies and recommendations for servers that are running Exchange Server in hardware virtualization environments

KB909840 - Hardware virtualization support for SharePoint products and technologies

KB958664 - Windows Server system software that is not supported in a Hyper-V virtual machine environment

KB888794 - Considerations when hosting Active Directory domain controller in virtual hosting environments

KB954418 - Sleep and hibernate power features are not available when you enable Hyper-V technology on a Windows Server 2008-based portable computer

KB944987 - Support partners for non-Microsoft hardware virtualization software

 

Mises à jours

 

KB950050 - Description of the update for the release version of the Hyper-V technology for Windows Server 2008

KB951636 - Description of the Hyper-V Language Pack for Windows Server 2008

KB956710 - A Hyper-V update is available to increase the number of logical processors and virtual machines on a Windows Server 2008 x64-based computer

KB952627 - Description of the Windows Vista Service Pack 1 Management Tools update for the release version of Hyper-V

KB951308 - Increased functionality and virtual machine control in the Windows Server 2008 Failover Cluster Management console for the Hyper-V role

 

Problèmes

 

KB950182 - A computer that is running an x86-based version of Windows Server 2008 or an x86-based version of Windows Vista may use fewer processors than expected if the number of cores on a socket is not a power of 2

KB956774 - A Background Intelligent Transfer Service (BITS) client cannot handle files that have paths that contain the volume GUID in Windows Server 2008 or in Windows Vista

KB956697 - Windows Server 2008 Hyper-V VSS writer is not used during a backup job because of corrupted or invalid virtual machine configuration files

KB950792 - When you try to enable, disable, or update Hyper-V technology, the process stops responding

KB949222 - Virtual machines that were created on the beta version of the Hyper-V role do not start after the Hyper-V role is updated to a later version

KB953828 - The NLB host does not converge as expected on Windows Server 2008 Hyper-V virtual machines

KB953585 - Error message when you try to start a Hyper-V virtual machine on a Windows Server 2008-based or Windows Vista-based computer that uses the NUMA architecture: "An error occurred while attempting to change the state of virtual machine VMNAME"

KB958829 - When Hyper-V is installed in SBS 2008 it causes the bindings for DHCP to bind to the incorrect interface

KB960038 - You receive a "0x0000007E" Stop error on Windows Server 2008-based computers that host Hyper-V virtual machines when you use the Hyper-V writer to back up virtual machines

KB954282 - The VMBus device does not load on a virtual machine that is running on a Windows Server 2008-based computer that has Hyper-V installed

KB959978 - Error message when you back up a Windows Server 2003-based virtual machine on a Windows Server 2008 Hyper-V-based computer: "GetWriterStatus FAILED for Selected writer [Microsoft Hyper-V VSS Writer], writer is in state [9] [VSS_WS_FAILED_AT_FREEZE]"

KB957967 - Stop error message on a Windows Server 2008-based computer that has the Hyper-V role installed: "STOP 0x0000001A"

KB954281 - After you install Windows 2000 on a virtual machine that is running on a Windows Server 2008-based computer that uses Hyper-V technology, you can only create a maximum startup disk that is 127 GB

KB958184 - Virtual machine backup operations fail in Windows Server 2008 when Hyper-V virtual machine files are saved on a volume that is mounted on a failover cluster by using a volume GUID

KB958065 - You cannot configure a Hyper-V virtual machine by using Windows Server 2008 Failover Clustering when the virtual machine uses a storage device that is managed by a third-party clustered file system or a third-party replication solution

KB954279 - You are not prompted for credentials after you receive an "Access Denied" error message when you try to connect to a virtual machine from the Windows Server 2008 Hyper-V MMC snap-in

KB954280 - Error message when you try to export a virtual machine on a Windows Server 2008-based computer that uses Hyper-V: "An error occurred while attempting to export the virtual machine"

KB954356 - After you deploy a Sysprep prepared image, the Hypervisor layer service does not start automatically in Windows Server 2008

KB958668 - You cannot shutdown a locked Windows 2000 SP4 virtual machine in Hyper-V Manager on a server that is running Windows Server 2008

KB959781 - Windows 2000 with Integration Services may shut down slowly while running as a guest on Server 2008 with Hyper-V

KB960024 - Error message when you try to create a new virtual machine in Windows Vista or Windows Server 2008: "The Encountered an Error while creating a Virtual Machine"

KB958665 - You do not receive an error message after you restore a Windows Server 2008 Hyper-V virtual machine

 

System Center Virtual Machine Manager

 

KB956589 - Description of the Hyper-V update for issues that may occur when you manage the Hyper-V role on the 64-bit editions of Windows Server 2008 by using SCVMM

 

How to

 

KB958662 - How to back up Hyper-V virtual machines from the parent partition on a Windows Server 2008-based computer by using Windows Server Backup

KB958663 - How to move a virtual machine that is running on Microsoft Virtual Server to a Windows Server 2008 Hyper-V environment

 

Guillaume

Windows Core Support Escalation Engineer

Avez-vous déjà rencontré un article de base de connaissances Microsoft ou vous êtes vous déjà vu présenter une solution Windows Error Reporting (WER) et demandé pourquoi Microsoft ne pouvait pas corriger cela pour vous ?

Aujourd'hui les articles KB et les solutions WER vous fournissent les étapes qui permettent de résoudre votre problème. Dans l’avenir nous espérons automatiser le plus de solutions et mettre en place un mécanisme qui permettra de résoudre les problèmes que vous avez avec nos produits plus rapidement et plus facilement en exécutant pour vous les actions documentées.

C’est l’objectif de l’initiative Fix it qui est déjà implémentée dans deux articles techniques :

• You receive "Runtime Error" messages when you view Web pages in Internet Explorer : http://support.microsoft.com/kb/822521
• The Internet Explorer icon is missing from your desktop : http://support.microsoft.com/kb/945402

 

Autre nouveauté (qui date un peu tout de même !), la possibilité de télécharger les correctifs n’étant pas disponibles sur Microsoft Updates et corrigeant des problématiques très spécifiques grâce au programme Hotfix Online Submission.

Pour ce type de correctif, vous devriez voir ceci en haut des fiches techniques un lien symbolisé par l’image ci-dessous :

En cliquant sur ce lien, vous serez à même de sélectionner la version qui convient à votre environnement (x86 ou x64) et le télécharger.

Ce projet vise à rendre plus fluide la délivrance des correctifs à nos clients alors que jusqu'à présent, il fallait passer un appel au support pour ouvrir un dossier (non décompté dans les contrats de support), être contacté par un ingénieur support qui identifiait la plateforme cible, la langue, etc... pour ensuite recevoir le correctif.

C’est plus simple non ?

 

Guillaume

Windows Core Support Escalation Engineer

Hervé Chapalain aura l’occasion de présenter une session orientée debugging le Mardi 10 Février. Ne manquez pas cette session et profitez du talent d’Hervé pour découvrir le quotidien d’un ingénieur support dans l’équipe Windows Core !

Session FRA408 - Débogage d’applications en production (Web, Service NT et autres…)

Des problèmes de crash, de fuites mémoires, de performances, ou tout autres bogues insaisissables sur votre site Web ? Cette session est faite pour vous. En direct du centre d'escalade Européen, venez rencontrer Hervé Chapalain, qui nous propose de voir les outils et méthodologie lorsque nous rencontrons ce type de situation. De l'utilisation des symboles, des dumps et autre bonne pratiques, Hervé se propose de vous montrer le « Microsoft Windows Performance Toolkit », ainsi que quelques trucs et astuces méconnus de Windows Vista et Windows 2008.

Pour vous mettre en bouche, la session de l’an passée Déboguer avec Visual Studio 2008.

 

L’équipe de Support Windows Core

L’équipe TechNet est heureuse d’offir 20% de réduction aux IT Pros pour tout nouvel achat d’un Abonnement TechNet Plus auprès de Microsoft.

Pour en bénéficier, utilisez le code promotion TNFR09 lors de votre achat en ligne ou par téléphone.

De plus, sachez que pour toute certification passée et réussie via le centre de test Edugroupe, un Abonnement TechNet Plus Direct d’une durée d’un an  vous sera offert !

Profitez-en dès maintenant si vous êtes sur le point de vous certifier prochainement !

Cette offre originellement valable jusqu’au 31 Janvier 2009 a été étendue jusqu'aux Microsoft Techdays 2009 inclus, qui auront lieu les 10, 11 et 12 février 2009 au Palais des Congrès de Paris où une offre spéciale vous attend sur le stand carrière du village Microsoft.