2013-10-31 17 views
5

Ich beginne einen Prototyp mit einem Windows-Minifilter. Ich habe meine Umgebung eingerichtet:Ich kann nicht brechen beim Anhängen an Zielmaschine im Kernel-Debug-Modus

  • ein Ziel Virtual Machine (eigentlich 3: ein Windows 7, 8 und 8.1)
  • eine Host-Entwicklungsmaschine (die Visual Studio 2013 und Hyper-V-VMs hostet)

ich es endlich geschafft, den Test auf Mini auf die Zielmaschine zu implementieren, aber mein Problem ist:

ich den Kernel in der Zielmaschine nicht brechen kann.

Wenn ich einen Build und starten von Visual Studio Debugger machen, hier ist das Ergebnis:

----------------------------------------------------------------------- 
----------------------------------------------------------------------- 
        Starting New Debugger Session   
----------------------------------------------------------------------- 
----------------------------------------------------------------------- 

Microsoft (R) Windows Debugger Version 6.3.9600.16384 AMD64 
Copyright (c) Microsoft Corporation. All rights reserved. 

MONTLUC\pascal (npipe WinIDE_01CED6303D19BD92) connected at Thu Oct 31 12:56:31 2013 

Microsoft (R) Windows Debugger Version 6.3.9600.16384 AMD64 
Copyright (c) Microsoft Corporation. All rights reserved. 

Waiting for pipe \\montlucw81x64\pipe\dbg 
Waiting to reconnect... 
[12:56:32:860]: Removing any existing files from the remote driver folder 
[12:56:33:121]: Removing any existing files from test execution folder 

te.exe "%SystemDrive%\DriverTest\Run\DriverTestTasks.dll" /select:"@Name='DriverTestTasks::_DriverRemoval'" /p:"InfFile=passThrough.inf" /p:"Debug=1" /p:"ImportDriver=1" /p:"RemoveDriver=1" /p:"CertificateFile=package.cer" /p:"PackageGuid={A23BA0FC-7265-4E3C-B99F-1E7A04AD970D}" /rebootStateFile:%SystemDrive%\DriverTest\Logs\DriverTestReboot.xml /enableWttLogging /wttDeviceString:$LogFile:file="%SystemDrive%\DriverTest\Logs\Driver_Removal_(x64)_(possible_reboot)_00060.wtl",writemode=append,encoding=unicode,nofscache=true,EnableLvl="WexStartTest|WexEndTest|WexXml|WexProperty|WexCreateContext|WexCloseContext|*" /runas:Elevated 
[12:56:56:926]: Result Summary: Total=1, Passed=1, Failed=0, Blocked=0, Warned=0, Skipped=0 
[12:56:57:457]: Removing any existing files from test execution folder 

te.exe "%SystemDrive%\DriverTest\Run\DriverTestTasks.dll" /select:"@Name='DriverTestTasks::_DriverPreparation'" /p:"InfFile=passThrough.inf" /p:"Debug=1" /p:"ImportDriver=1" /p:"RemoveDriver=1" /p:"CertificateFile=package.cer" /p:"PackageGuid={A23BA0FC-7265-4E3C-B99F-1E7A04AD970D}" /rebootStateFile:%SystemDrive%\DriverTest\Logs\DriverTestReboot.xml /enableWttLogging /wttDeviceString:$LogFile:file="%SystemDrive%\DriverTest\Logs\Driver_Preparation_(x64)_(possible_reboot)_00060.wtl",writemode=append,encoding=unicode,nofscache=true,EnableLvl="WexStartTest|WexEndTest|WexXml|WexProperty|WexCreateContext|WexCloseContext|*" /runas:Elevated 
[12:57:00:437]: Result Summary: Total=1, Passed=1, Failed=0, Blocked=0, Warned=0, Skipped=0 
[12:57:00:893]: Removing any existing files from test execution folder 

te.exe "%SystemDrive%\DriverTest\Run\DriverTestTasks.dll" /select:"@Name='DriverTestTasks::_RunProcess'" /p:"BinaryPath=rundll32" /p:"Arguments=setupapi,InstallHinfSection DefaultInstall 132 C:\DriverTest\Drivers\passthrough.inf" /p:"ExitCodes=0" /p:"WorkingFolder=%SystemDrive%\DriverTest\Drivers" /p:"LogOutput=1" /rebootStateFile:%SystemDrive%\DriverTest\Logs\DriverTestReboot.xml /enableWttLogging /wttDeviceString:$LogFile:file="%SystemDrive%\DriverTest\Logs\Driver_Install_(x64)_(possible_reboot)_00025.wtl",writemode=append,encoding=unicode,nofscache=true,EnableLvl="WexStartTest|WexEndTest|WexXml|WexProperty|WexCreateContext|WexCloseContext|*" /runas:Elevated 
[12:57:03:916]: Result Summary: Total=1, Passed=1, Failed=0, Blocked=0, Warned=0, Skipped=0 
[12:57:04:418]: Removing any existing files from test execution folder 

te.exe "%SystemDrive%\DriverTest\Run\DriverTestTasks.dll" /select:"@Name='DriverTestTasks::_DriverPostInstall'" /rebootStateFile:%SystemDrive%\DriverTest\Logs\DriverTestReboot.xml /enableWttLogging /wttDeviceString:$LogFile:file="%SystemDrive%\DriverTest\Logs\Driver_Post_Install_Actions_(x64)_(possible_reboot)_00060.wtl",writemode=append,encoding=unicode,nofscache=true,EnableLvl="WexStartTest|WexEndTest|WexXml|WexProperty|WexCreateContext|WexCloseContext|*" /runas:Elevated 
[12:57:06:139]: Result Summary: Total=1, Passed=1, Failed=0, Blocked=0, Warned=0, Skipped=0 
[12:57:06:564]: Driver Installation summary: 
[12:57:06:566]: Driver Removal (x64) (possible reboot): Pass 
[12:57:06:571]: Driver Preparation (x64) (possible reboot): Pass 
[12:57:06:578]: Driver Install (x64) (possible reboot): Pass 
[12:57:06:586]: Driver Post Install Actions (x64) (possible reboot): Pass 

Und wenn ich zu brechen versuchen, passiert nichts.

Wenn ich direkt an den Kernel anhängen (mit VS-Menü "Debug" -> "Anhängen zu verarbeiten" -> "Kernel-Debugging" -> "Attach", bekomme ich diese:

----------------------------------------------------------------------- 
----------------------------------------------------------------------- 
        Starting New Debugger Session   
----------------------------------------------------------------------- 
----------------------------------------------------------------------- 

Microsoft (R) Windows Debugger Version 6.3.9600.16384 AMD64 
Copyright (c) Microsoft Corporation. All rights reserved. 

MONTLUC\pascal (npipe WinIDE_01CED630A522D2F5) connected at Thu Oct 31 12:59:26 2013 

Microsoft (R) Windows Debugger Version 6.3.9600.16384 AMD64 
Copyright (c) Microsoft Corporation. All rights reserved. 

Waiting for pipe \\montlucw81x64\pipe\dbg 
Waiting to reconnect... 

Aber wieder . unmöglich, zu brechen

ich habe versucht:

  • alle Ziel-Hosts (Windows 7, 8 und 8.1) und bekam das gleiche Ergebnis (und ja, sind sie alle richtig für Kerneldebuggen konfiguriert)
  • anstelle von Named Pipes
  • mit WinDBG anstelle von Visual Studio 1.363.210
  • Netzwerk mit

Aber ich habe immer das gleiche Ergebnis: unmöglich zu brechen diesen @ # Kernel!

Google ist nicht mein Freund, ich konnte kein ähnliches Problem finden.

So, jetzt frage ich mich:

  • Könnte ich auf die Zielmaschine tatsächlich nicht angeschlossen werden, trotz allem, was der Debugger sagt (aber Bereitstellung Werke)?
  • Könnte es ein Problem mit HyperV und Kernel-Debugging geben?

Jede Idee willkommen!


bearbeiten: Ich habe einen Test mit einer echten Zielmaschine habe statt einem virtuellen, und ich habe das gleiche Problem, so ist dies nicht zu Hyper-V zusammen.

Antwort

6

löste ich mein Problem (ich sauge, also bin ich)

Auf den Punkt gebracht, ist hier, wie die beiden Maschinen für Kerneldebuggen konfiguriert werden muss.

A.Zielmaschine (Hyper-V VM)

  • Konfigurieren für Kerneldebuggen (mit msconfig ist der einfachste Weg) auf serielle COM1
  • Konfigurieren von Hyper-V-Maschine Rohr COM1 zu einem Named Pipe (\. \ Pipe \ debug beispiel)

B. Quelle Maschine (Hyper-V-Host-Hosting des Ziel)

  • Run WinDBG oder VS in Admin-Modus (das Fehler war meine erste)
  • Eine Verbindung mit Named Pipe mit genau dem gleichen Namen (\. \ pipe \ debug) (das war mein zweiter Fehler, ich dachte, der Maschinenname eigentlicher Zielname)

sein mußte Es funktioniert gut, mit einer netten Integration unter Visual Studio 2013. Dank an alle, die (niemand) geantwortet hat ... Und alle anderen, die lesen :)