Overview

Quick Start

kd> .symfix

kd> .srcfix
Source search path is: SRV*

kd> .reload
...

kd> bp Wdf01000!FxDevice::DispatchWithLock
kd> g
Breakpoint 0 hit
Wdf01000!FxDevice::DispatchWithLock:
87131670 8bff mov edi,edi

WinDbg Setup

Enable Source Mode Debugging

Clear Stale Symbols Cache

kd> !lmi Wdf01000.sys
Loaded Module Info: [wdf01000.sys]
...
Load Report: private symbols & lines, not source indexed
C:\...\Wdf01000.pdb\...\Wdf01000.pdb

kd> .reload /u Wdf01000.sys

kd> !lmi Wdf01000.sys
Loaded Module Info: [wdf01000.sys]
...
Load Report: private symbols & lines, source indexed
C:\...\Wdf01000.pdb\...\Wdf01000.pdb

• Examine the driver’s WDF I/O request completion rate and examine the corresponding sampled CPU utilization.
• Compare a UMDF 2 driver against a similar KMDF driver and determine if UMDF meets your performance requirements.
• Determine which instance of a given PnP or power related callback is taking a long time to complete. Then examine sampled CPU usage to understand why.
• Check if your device is making power transitions in and out of the D0 power state more frequently or not as frequently as you'd expect.

Information about this feature and interpreting the data is available in the documentation here. More information about the performance toolkit and the performance analyzer is available here.

We'd love to hear your feedback!

- WDF Team.

With this release, the HLK can be used to submit drivers to the Windows Hardware Compatibility Program.  Download the Compatibility Program Playlist to determine which HLK tests are required to certify your system or device for the program. Read more details on this blog.

As you use these kits, please let us know your feedback in the section below

Last week at our WinHEC conference, we introduced many of the great new features we’ve enabled with the Windows 10 hardware developer kits. We’re excited to announce that those kits are now available. Sign up to be a Windows Insider for access to the WDK, ADK, and HLK. These tools will enable you to try out every scenario showcased by Don Box in his keynote.

As you use these kits, please let us know what you think in the comment section below.

Cheers,

J M Rossy on behalf of the hardware kits team.

Goal

Our goal with the WDF has always been to make it straightforward to write high-quality drivers.  The frameworks abstract away much of the underlying OS internals without sacrificing flexibility when it’s needed. Combine that with the world-class development environment we’ve enabled with Visual Studio and the Windows Driver Kit (WDK). The end result is a great experience for Windows 10 driver developers.

Still, we understand there’s no substitute for having OS source available. That’s why we’ve published the source behind WDF for anyone to dig through and debug their drivers with. This gives developers transparency into exactly what the framework does as their drivers interact with it. We encourage you to download the source and try stepping through it with the kernel debugger.

Scope

With this initial release, we’ve published the source behind KMDF and UMDF v2. You’ll find that a great deal of the source is shared between the two. Driving the frameworks forward with a unified model is a key priority for WDF the team.

As you experiment with WDF, you may come across undocumented behavior or APIs. We strongly advise against taking dependencies on that behavior as it’s subject to change in future releases. 

If you think of features you’d like to see added or find suspected bugs in the source, we encourage you to file those in the GitHub repo issue tracking. Some of you may be keen on making contributions back to the framework. For the moment, we aren’t accepting contributions via GitHub pull requests. We’re still evaluating that option and it may change in the future.

Samples

We’re also pleased to announce that, like WDF, the collection driver sample projects will now live on GitHub. The set of Windows 8.1 samples on MSDN Code Gallery will stay there for now but all new/updated samples for Windows 10 can be found in github.com/Microsoft/Windows-Driver-Samples.

We believe that making the WDF source available to anyone is a big step forward for Windows hardware enablement. As we continue to roll out new tools, source, and docs, we’re really excited to see the amazing new Windows-enabled devices that you bring to market.

Cheers,

J M Rossy on behalf of the WDF team.

Sharks Cove is a hardware development board that you can use to develop hardware and drivers for Windows. The Intel Sharks Cove board supports driver development for devices that use a variety of interfaces, including GPIO, I2C, I2S, UART, SDIO, and USB. You can also use the Sharks Cove board to develop drivers for cameras and touch screens.

For information about the Sharks Cove board, see www.sharkscove.org. 

For details about Windows compatible hardware development boards, see www.msdn.microsoft.com/hardwaredevboard

Here’s the blog in his own words.

In this post, I wanted to provide more of a walkthrough on the process of setting up a Sharks Cove for installing and debugging a driver. This post is a direct result of my experience working with the board. Currently, there is a step-by-step guide to setting up and using Sharks Cove on MSDN, so I will not cover everything in detail. Instead, I’d like to look at each of the steps and provide the details of my experience.

Sharks Cove setup

You can absolutely skip this section if you have the board already setup and provisioned or the link above is sufficient. This section is merely to provide clarification from my experience setting up the board. Starting from the top, you will need to gather your hardware. My setup was as follows:

• A monitor accepting DVI input
• An HDMI cable and HDMI-DVI adapter
• A powered USB hub
• USB Mouse\Keyboard
• USB Ethernet adapter for network access
• USB to micro USB cable for kernel debugging

After initial setup, it is possible to get away without a monitor for the Sharks Cove as you can simply remote into the machine from your host machine. The next step involves setting up your host machine. I think the documentation for this section covers it. You simply need Visual Studio Express, which is free, if you don’t already have it. Then, you’ll need to download and install the WDK 8.1 Update. This kit installs all of the necessary files to write drivers for Windows 8.1 Update, 8.1, 8, and 7. The kit is integrated into Visual Studio so you can develop and deploy drivers from within Visual Studio. My experience with this integration was positive. In general, the workflow is very fluid when compared to debugging separately through WinDbg or KD.

Now, we have arrived at setting up the Windows Image and installing it onto the dev board. To me, this step looks overwhelming, but I assure you that it is fairly simple and the documentation has you covered. Once you have successfully created an image, keep it around on a USB in case you ever need to reimage the board. The documentation directs users to download Windows Embedded 8.1 Industry Pro Evaluation. This is a trial OS option for available to developers, but in my experience, the board can run any version of Windows client image you want to install.

Next we need to provision the target system. In this scenario, your host machine is the machine you set up earlier with the WDK and Visual Studio. The target machine is the dev board. The documentation has a link for setting up a target, and that should be enough because provisioning for the Sharks Cove is just like any other target. Here’s a short version of this process, explicitly stating what is happening on each machine.

• Get the WDK Test Target Setup msi from the host (development) machine and bring it to the target (Sharks Cove) via USB or network if that is setup.
• Run this on the target.
• Once that is run, you can finish provisioning in Visual Studio on the host machine. I’d recommend reading through both the provisioning steps and setting up kernel debugging links provided in this section before doing either. That’s because
  you’ll want to select Provision computer and choose debugger settings the first time through so you don’t have to do the process twice.

Attaching a component

The documentation gives an example of the ASL entry for an ADXL345 accelerometer. This is the part that I worked with to test the board, so I’ll talk about using that part through the remainder of this post. To attach the part, I used a breadboard,
but with the proper cables, you can just connect it directly. The pin mappings can be found in this guide (SpbAccelerometer driver cookbook). Once connected, just follow the steps detailed in Step 6 from the Sharks Cove guide we’ve been following. The ASL entry I used during development looked slightly different: Device(ADXL) instead of Device(SPBA) and Name(_HID, “ADXL345”) instead of Name(_HID, “SpbAccelerometer”).  Pay attention to these fields in whatever
version of the ASL entry you see available at the time of reading this. It will be important when installing your driver.

Installing and debugging a driver

Using the sample driver linked at the bottom of the page, you can test your part. After opening the solution, be sure to set the configuration platform in Visual Studio. The instructions are on the sample’s documentation page. Be sure to set it to a
debug configuration or you may encounter signing issues. The simplest method of building and testing the driver is through Visual Studio itself.  Right click the package project and select properties. Under Driver Install > Deployment, enable deployment, set your target machine to Sharks Cove, and select Install and Verify. Click OK, and you can begin debugging by clicking Debug > Start Debugging. This should build the driver, connect to Sharks Cove, copy over the driver files, install it, and finally attach to it for debugging. If the build is successful, you should see various cmd windows popping up and closing on the Sharks Cove. After they are finished, if successful, a Debugger Immediate Window will appear in
Visual Studio already broken into upon driver load. You can then set break points, continue, break, and step through code like normal with Visual Studio.

The alternative to using Visual Studio to deploy and debug is manual deployment and debugging with WinDbg (included in the WDK). Instructions for manual deployment can be found on the sample’s documentation page. Before you install the driver with devcon, you will need to do some setup so that you can attached to the driver on load with WinDbg. First, you need to copy wdfverifier.exe from …\Windows Kits\8.1\Tools\x86\ on the host to your Sharks Cove. This tool will allow you to set WUDFHost.exe, the process that hosts the driver, to break when your driver is loaded. Run it on the Sharks Cove. Go to the Global WDF Settings tab. Where it says, “At [driver load\start], Host Process will wait [0] seconds for user-mode debugger,” set the dropdown to driver load and the time to 10 or more seconds. You should check the kernel debugger checkbox below this if you plan on kernel debugging. When you install your driver, WUDFHost.exe will break upon you driver loading and wait as long as you specified. At this point you need to attach a debugger. For user-mode debugging, you need to run WinDbg as an administrator on the Sharks Cove. Click File > Attach to process. Find WUDFHost.exe and attach. If you have multiple WUDFHost.exe processes, use tasklist /M SpbAccelerometer.dll from the command line to get the PID of the correct WUDFHost.exe. You can now attach a remote WinDbg session to this one from your host machine if you
prefer. To do this simply run .server npipe:pipe=<pipename> in the WinDbg session on your Sharkscove where pipename is whatever you prefer. Next, start a WinDbg session on your host and click File > Connect to a Remote Session. You will need to type the output of the .server command after –remote (e.g. npipe:pipe=examplepipe,server=examplehost). Lastly, you can kernel debug through USB if it is setup. Simply start WinDbg on your host and click File > Kernel Debug. Select the COM tab and change the port to comX where X is the number you found for the target when provisioning. Once attached in all cases, you will need the symbols for your driver, the pdb file in the binary output of your Visual Studio project. You can either copy it to your Sharks Cove for local debugging or keep it in place and attach remotely to the Sharks Cove. Whichever method you choose, in WinDbg, on the host unless using the first option, select File > Symbol File Path. Add the full path to the directory containing the pdb file. If you’d like to look at or step through source code, add the full path to the directory containing the source files for the driver in File > Source File Path. Paths are separated by a semicolon. Links to debugging with WinDbg can be found in the Sharks Cove documentation.

Tips and Tricks

I wanted to close with a few things that I did to make my life easier when working with Sharks Cove. There’s nothing fancy here, just stuff that you may or may not find useful or already thought of yourself.

• Pinning things to the taskbar can save you a bit of time. I pinned cmd as admin to the taskbar. If you don’t know how to make it launch as admin by default, pin it, right click the pinned icon, right click the program name, click properties, click Advanced, and then check Run as Administrator. I also pinned WinDbg. I also pinned File Explorer.
• Speaking of pinning, I pinned C:\DriverTest to my favorites in File Explorer. This is the folder on the target where your driver is deployed to by the WDK.
• I adjusted the power options on the Sharks Cove to keep it from going to sleep.
• Two options if you aren’t kernel debugging and don’t have a second keyboard\mouse setup:
  • Mouse without borders: a program that allows you to use one set of mouse and keyboard over multiple devices
  • Remote desktop (also doesn’t require a second monitor)
  • In WinDbg, you can create workspaces in the File menu. I used these to save the paths to symbols and source file for my driver, so I didn’t have to do it every time.

So there it is, pretty much my knowledge and experience on the Sharks Cove. I hope this is helpful to those getting started, because I want to be able to help those who are having similar experiences as me.

We also have an exciting new hardware development to disclose.

Event Information
Date: August 25, 2014
Time: 2 live-broadcasts; 10am PST, 5pm PST
Online Venue: https://channel9.msdn.com/

Sharks Cove is currently available for order globally at www.sharkscove.org

Go to https://www.msdn.microsoft.com/hardwaredevboard to learn more about Windows compatible hardware development boards.

We hope to see you at the event.

The Sharks Cove development board is now available for pre-order!

This marks a major milestone in our work, and we’re all pretty excited about it, to say the least.  This board is the product of a lot of collaborative effort amongst various groups from Microsoft and Intel.  This “Windows compatible hardware development board” is designed to facilitate development of software and drivers for mobile devices that run Windows, such as phones, tablets and similar System on a Chip (SoC) platforms. 

At $299, this is a board that we believe will find a home with Independent Hardware Vendors (IHVs) and hardware enthusiasts alike.  That price not only covers the cost of the hardware, but also includes a Windows 8.1 image and the utilities necessary to apply it to the Sharks Cove.  When you additionally consider that the Windows Driver Kit 8.1 can pair with Visual Studio Express and are both free with a valid MSDN account, the initial outlay for Windows driver developers is a lot less cost prohibitive than it once was.

We’ve also been busy posting content related to the Sharks Cove, settling into our new MSDN development-board Forum, and the launch of this blog.  Our goal is to ensure information is easily found and we have multiple ways to interact with
our community:

SharksCove.org is the site we have set up a site dedicated to the Sharks Cove board, where you’ll find specs and links to other content and our MSDN forums, as well as a link for the pre-order.

Pre-order the Sharks Cove direct link (via Mouser Electronics).

The Hardware Development Boards for Windows forum on MSDN is the new forum we have set up for discussion and support.

The Windows compatible hardware development boards MSDN page will consistently be updated with new information and act as a launch point to the various pages related to Windows driver development using these boards. 

As mentioned above, Peter Wieland and Viraf Gandi introduced and demoed the Sharks Cove at the //BUILD conference in San Francisco this past April – definitely worth the viewing!

Over the next few weeks and months, we’re planning to a number of articles related to the Sharks Cove and using it for driver development.  Among our planned posts, we will have series of posts from our summer college intern describing his introduction to driver development and using the Sharks Cove and the User Mode Driver Framework (UMDF) to develop a sensor driver.  We’ll also give a behind-the-scenes peek at how all of this came together, as well as a variety of other posts that feature the Sharks Cove.

We’re very excited and proud of the work done to make the Sharks Cove a reality.  We are looking forward to seeing the amazing things that can be done with these boards!

 -------------------------------------------------------------------------

UPDATE: We’ve seen a lot of news along with robust comments since our blog post announcing Sharks Cove pre-order availability and it’s exciting to see all the interest!  However, we want to provide more clarity as we are seeing a lot of direct comparisons between Sharks Cove and Raspberry Pi. The primary focus for Sharks Cove is to support Windows IHV’s and ODM’s, who need a Windows compatible system that is appropriate for hardware and driver development.  Sharks Cove is a fully functional PC so you can install desktop and Windows Store apps to facilitate your development and testing and even your general enjoyment of the device. 

Our focus with this board doesn’t mean Microsoft isn’t also focused on bringing Windows to smaller devices.  For example, as part of presentations at the 2014 //Build conference and the O’Reilly 2014 Solid conference, Steve Teixeira demonstrated Windows running on an Intel Galileo board.  Earlier this month on July 11, the “Building Apps for Windows” blog introduced the Windows Developer Program for IOT .  This is the first of the several programs Microsoft will offer in the maker space. Many of the questions about Windows on Devices are covered in the FAQ found on the MS-IoT GitHub Open Source Home for the project.