📢 PUBLIC Page 1122:22/22
| 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
_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.
I removed "$(WDKPATH)\Include\shared;$(VS12PATH)\VC\Include" from the includes,
changed "Ignore common includes" to YES, and added
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.
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
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
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.
Create a symbols directory on VS17.
Zip up the entire symbols directory on VS12.
pkzip -add -dir ..\Symbols.zip *
move ..\Symbols.zip Z:\Share\
Unzip the symbols on VS17.
pkzip -ext -dir Z:\Share\Symbols.zip
Set the base symbol path.
File > Symbol File Path...
I do not want to include any online servers.
Save the workspace.
Add the CryptDisk output directory to the symbol path.
Save the workspace as "CryptDisk"
Create a launcher (a Start Menu link or a .bat file)
"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe"
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)
Create a new VS17 network adapter.
VM > Settings... > Hardware > Add...
Network adapter > Finish
Network connection > Custom > VMnet8 (NAT)
Use ipconfig to determine the new IP address.
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.
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
Launch WinDbg on VS17.
Restart the target.
The target should now connect to windbg.
Build, Deploy, Debug
Rebuild the solution on VS17.
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
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.
Launch WinDbg on VS17.
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.
Launch Remote Debugger on Win10Target.
(If it does not launch automatically.)
msvsmon may spontaneously quit due to VM networking problems.
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
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
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.
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.
I get this error when I try to compile a single file:
1>------ Build started: Project: CryptDisk, Configuration: Debug x64 ------
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.
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.