n l i t e d

:
Contact |  Home |  Recent | 


Thread Links
next

VS2017
📢 PUBLIC Page 1122:22/22 | edit | chip 2018-04-15 13:11:17

Dec 22 2017

I am migrating the CryptDisk project from Visual Studio 2015 to VS2017.

WARNING: This is a one-way upgrade! Once these changes have been applied to the project and target, they will be unusable in Visual Studio 2015 or earlier.

The WDK directories have been reorganized.

The WDK include directories now include a version:
C:\Program Files (x86)\Windows Kits\10\include\10.0.16299.0
C:\Program Files (x86)\Windows Kits\10\Lib\10.0.16299.0\km\x64
I installed the base Visual Studio to
C:\VS\2017
The build tools (dumpbin) are found in
C:\VS\2017\VC\Tools\MSVC\14.12.25827\bin\Hostx64\x64

_MSC_VER has been bumped from 1800 to 1900.

Unresolved external __stdio_common_vsprintf invoked by RtlStringCbVPrintfA().

Looking at the assembly output, it appears that RtlStringCbVPrintfA() is somehow being satisfied by ucrt\stdio.h.

Device.cod: // Called to complete an IRP that failed. NTSTATUS DeviceExt::IrpFail(IRP *pIrp, NTSTATUS Status, ULONG_PTR Info, const char *Fmt, ...) { char Text[200]; va_list ArgList; va_start(ArgList,Fmt); RtlStringCbVPrintfA(Text,sizeof(Text),Fmt,ArgList); Warn(Status,"DeviceExt:IrpFail: %s",Text); va_end(ArgList); IrpComplete(pIrp,Status,Info); return(Status); } ; 176 : NTSTATUS DeviceExt::IrpFail(IRP *pIrp, NTSTATUS Status, ULONG_PTR Info, const char *Fmt, ...) { $LN26: 00000 40 53 push rbx 00002 55 push rbp 00003 56 push rsi 00004 57 push rdi 00005 41 56 push r14 00007 48 81 ec 00 01 00 00 sub rsp, 256 ; 00000100H 0000e 49 8b f1 mov rsi, r9 ; 177 : char Text[200]; ; 178 : va_list ArgList; ; 179 : va_start(ArgList,Fmt); 00011 4c 8d b4 24 58 01 00 00 lea r14, QWORD PTR Fmt$[rsp+8] 00019 41 8b d8 mov ebx, r8d 0001c 48 8b ea mov rbp, rdx 0001f 48 8b f9 mov rdi, rcx ; File c:\program files (x86)\windows kits\10\include\10.0.16299.0\ucrt\stdio.h ; 1388 : int const _Result = __stdio_common_vsprintf( 00022 e8 00 00 00 00 call __local_stdio_printf_options

I removed "$(WDKPATH)\Include\shared;$(VS12PATH)\VC\Include" from the includes, changed "Ignore common includes" to YES, and added
$(WDKPATH)\Include\$(WDKVER)\km;
$(WDKPATH)\Include\$(WDKVER)\km\crt;
$(WDKPATH)\Include\$(WDKVER)\shared
I was then able to link.

These changes were then replicated on the CryptIFS project.

Driver signing failed. I confirmed that the certificate is valid and matches the one I created on Oct 27 2017. It seems I need to have the certificate file and have the certificate stored in my personal store on the machine.

Driver Signing: 2>Signing "S:\Src\HQ\Dev\SB\Chip\VirtualDisk\CryptDisk\Out\Winx64Debug\CryptDriver2.sys" using "nlited systems inc." certificate ... 2> 1 file(s) copied. 2>EXEC : SignTool error : No certificates were found that met all the given criteria. 2>C:\VS\2017\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(203,5): error MSB3073: The command "S:\Src\HQ\Dev\SB\Chip\VirtualDisk\CryptDisk\Bin\BldSign.bat "nlited systems inc." "S:\Src\HQ\Dev\SB\Chip\VirtualDisk\CryptDisk\Bin\MSCV_VSClass3.cer" "S:\Src\HQ\Dev\SB\Chip\VirtualDisk\CryptDisk\Driver2\Out\Winx64Debug\CryptDriver2.sys" "S:\Src\HQ\Dev\SB\Chip\VirtualDisk\CryptDisk\Out\Winx64Debug\CryptDriver2.sys" "S:\Src\HQ\Dev\SB\Chip\VirtualDisk\CryptDisk\Driver2\Out\Winx64Debug\DriverSigning.log" 2>C:\VS\2017\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(203,5): error MSB3073: :VCEnd" exited with code 1. 2>Done building project "Driver2.vcxproj" -- FAILED.

I exported the certificate from VS12 to K:\Keys\nlited_code_signing_cert.pfx and imported it to VS17 Personal by double-clicking the file. (Opening the certificate manager first doesn't work.) I was then able to sign the driver.

SUCCESS! After about 5 hours, the complete project builds. A big chunk of the time was spent scratching my head over the sprintf problem.

Local help docs are no longer part of the standard installation and adding them is buried under Tools > Get Tools and Features ... which insisted on updating the VS installer before I could do anything. An hour later I found "Help Viewer" in the "Individual Components" section under "Code Tools". Once the Help Viewer has been installed, I can go to Help > Set Help Preference > Launch in Help Viewer. I then need to download all the content, 1.2GB.

The download failed because it could not start BITS. I needed to be signed in as (not just elevated to) an admin to save the downloaded docs. Since the download is so large, I am going to wait to start it before I go to sleep tonight. See VS2017 Local Help.

The next task is to configure WinDbg and step through the driver code running on the Win10Target VM.

Launch WinDbg from
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe
Select File > Kernel Debug... and use Port 49999 and Key wt5hk...lie4et.

Boot Win10Target, and use BCDEdit to redirect the debugger to VS17.
bcdedit /dbgsettings net hostip:192.168.146.133 port:49999
Reboot Win10Target and this time VS17 should catch it.

Oops. I should have set the symbol configuration before launching WinTarget10, now VS17 is trying to download the symbols for everything and dropped the connection. I restarted again and I was able to halt the target. Then WinDbg went off downloading more symbols... I just need to sort out the symbol cache and I should be good to go.

I can avoid downloading all the symbols again (See Remote Debugging by copying them from VS12.

  1. Create a symbols directory on VS17.
    mkdir C:\VS\Symbols
  2. Zip up the entire symbols directory on VS12.
    cd D:\CL\Symbols\Win10 pkzip -add -dir ..\Symbols.zip * move ..\Symbols.zip Z:\Share\
  3. Unzip the symbols on VS17.
    cd C:\VS\Symbols pkzip -ext -dir Z:\Share\Symbols.zip del Z:\Share\Symbols.zip
  4. Launch WinDbg
  5. Set the base symbol path.
    File > Symbol File Path...
    I do not want to include any online servers.
    C:\VS\Symbols
  6. Save the workspace.
  7. Add the CryptDisk output directory to the symbol path.
    S:\Src\HQ\Dev\SB\Chip\VirtualDisk\CryptDisk\Out\Winx64Debug; C:\VS\Symbols
  8. Save the workspace as "CryptDisk"
  9. Create a launcher (a Start Menu link or a .bat file)
    "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe" -W CryptDisk -b -k net:port=49999,key=wt5hk1...lie4et

VM Network

See VM Network Configuration and Remote Debugging.

  1. The host should already have 3 virtual networks defined.
    Edit > Virtual Network Editor
    • VMnet0 Bridged: Used for external networks (internet)
    • VMnet1 Host-only: Used for VM to host communication.
    • VMnet8 NAT: Used for communication between VMs.
      This is the interface I want to use, note the subnet (192.168.146.X)
  2. Create a new VS17 network adapter.
    VM > Settings... > Hardware > Add...
    Network adapter > Finish
    Network connection > Custom > VMnet8 (NAT)
  3. Use ipconfig to determine the new IP address.
    192.168.146.134
  4. Allow everything on the 192.168.146.X subnet through the VS17 firewall.
    This is safe since 192.168.X.X is a non-routeable subnet.

    Confirm by pinging from Win10Target to VS17.
    ping 192.168.146.134
  5. Launch the target VM (Win10Target) to set the new debugger address.
    Create an admin console.
    bcdedit /dbgsettings net hostip:192.168.146.134 port:49999
  6. Launch WinDbg on VS17.
  7. Restart the target.
    The target should now connect to windbg.

Build, Deploy, Debug

  1. Rebuild the solution on VS17.
  2. Install Remote Debugger on the target
    NOTE: VS2017 requires its own updated remote debug monitor.
    1>Unable to connect to the Microsoft Visual Studio Remote Debugger named 'Win10Target:4020'. The remote debugger is older than this version of Visual Studio 2017, and Visual Studio is no longer compatible with it. Upgrade your remote debugger to match Visual Studio.
    I downloaded Remote Tools for Visual Studio 2017 and saved them in \\ColdStore01\Installers\Visual Studio\VS17_Remote_Tools.msi
    "C:\Program Files\Microsoft Visual Studio 15.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe"
    This needs to run as admin only to install the driver.
    I can use Task Scheduler to auto-start the remote debugger.
    Control Panel > System and Security > Administrative Tools > Schedule Tasks
  3. Configure Remote Debugging on the host (VS17)
    NOTE: The remote server name includes the port, which must match what is reported by msvcmon on the target.
  4. Launch WinDbg on VS17.
  5. Boot the target (Win10Target)
    Make sure the target connects to WinDbg.
    The target may stall while connected to WinDbg. It can be kicked by hitting Ctrl-Break and go in WinDbg.
  6. Launch Remote Debugger on Win10Target.
    (If it does not launch automatically.)
    msvsmon may spontaneously quit due to VM networking problems.
  7. Deploy to Win10Target.
    The 192.168.146.X subnet may not have domain DNS support, requiring the target computer to be referenced by its raw IP address. A better alternative is to define a private host in C:\Windows\System32\etc.
    192.168.146.132 target
  8. Debug.
    Debug the CryptDisk application from Visual Studio.
    The user-mode debug connection will timeout if WinDbg halts the target for more than 30 seconds. This is extremely annoying.

I had to upgrade the remote debugger on Win10Target to VS2017.

I had trouble using the NAT subnet (192.168.146.X) and switched to using the bridged subnet (VS17=192.168.0.201, Win10Target=192.168.0.211) instead. This was before I noticed that the remote port was mismatched, so I should try to use the NAT subnet again later.

I persevered and eventually made it to my DriverEntry() breakpoint.

VS17 is now fully operational!

Kernel Debug Using Visual Studio

I tried using Visual Studio to debug my kernel driver, to see if it had improved since VS2015. There seemed to be very little improvement, if any. The user mode and kernel mode debuggers still step on each other, the UM debugger still times out during KM breakpoints. It is actually worse than WinDbg, the KM debugger locks up until the UM session times out.

Resource Editor

I tried to create a new dialog and encountered this error:

A Windows Firewall dialog popped up and I allowed devenv.exe to poke another hole. The dialog editor then appeared.

FastLink

I get this error when I try to compile a single file:

FastLink: 1>------ Build started: Project: CryptDisk, Configuration: Debug x64 ------ 1>KeyMgr2.cpp 1>KeyMgr2.cpp : fatal error C1052: program database file, 'S:\Src\HQ\Dev\SB\Chip\VirtualDisk\CryptDisk\Out\Winx64Debug\CryptDisk.pdb', was generated by the linker with /DEBUG:fastlink; compiler cannot update such PDB files; please delete it or use /Fd to specify a different PDB filename 1>Done building project "CryptDisk.vcxproj" -- FAILED. ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

This is fixed by setting Project Properties > Linker > Debugging >
Generate Debug Info = DEBUG:FULL
Generate Full Program Database File = YES.

See: Blogs.MSDN.Microsoft.com


close comments Comments are closed.

Comments are moderated. Anonymous comments are not visible to other users until approved. The content of comments remains the intellectual property of the poster. Comments may be removed or reused (but not modified) by this site at any time without notice.

  1. [] ok delete

Page rendered by tikope in 293.832ms