Troubleshooting Common Surface Pro 3 Issues Post Deployment

With the launch of Surface Pro 3, enterprises have been testing/deploying them. Almost all deploy a customized image to Surface Pro 3 and sometimes they hit a roadblock. Today, I will talk about some of the basic things to check that can help narrow down the issues.

Before we get to that, I would like to point out couple of articles/blogs that everyone should refer before deploying Surface Pro 3. One of my colleagues, Scott McArthur, has an excellent blogon deploying Surface Pro 3 using MDT. I would highly recommend reading through it.

Deploy Windows to Surface Pro 3 using Microsoft Deployment Toolkit

We also have an updated Deployment Guide available for download.

Deployment and Administration Guide for Surface Pro 3

Now, on to troubleshooting issues.  The first question we want to ask is:

Can the issue be reproduced on a Windows tablet, PC or Virtual Machine?

If the issue can be reproduced on any other Windows tablet, PC or VM, then most likely it is a software issue and we treat it as a regular Windows 8.1 case.  As such, we would troubleshoot it as if you would any other Windows issue.

However, if the issue presents itself only on the Surface Pro 3, we need to narrow it down to the factory image or the customized image that is being deployed. If the issue happens with the factory image, it would be good idea to engage Microsoft.

When it happens only with customized image, we need to narrow it down further if its application, driver or OS related.

It starts with a supported Operating System. Based on KB2858199below chart represents supported Operating System. Please refer to the KB for any updates to this policy.


Make sure the device is up to date with the latest drivers and firmware. Driver and firmware updates are available via Windows Updates. They are also available for download from the following link.

Surface software, firmware, and drivers

In addition, the following link lists the fixes that are included with these updates.

Surface Pro 3 update history

clip_image002 Note:

Generic versions of drivers should not be included and avoided for Surface Pro 3 deployments. The reason is Surface Pro 3 drivers are specifically written for the device and other drivers are not optimized for the power management technology we use in the Surface. So, using a generic driver can cause all sorts of issues like crashes, reduced battery life, unstable system and others.

Once we know the OS that is being deployed is correct and we have the latest drivers and firmware, we would want to ask some of additional questions:

Can the issue be reproduced if we simply deploy the OS imported from an .iso and no other applications installed?

In other words, if we install Windows using a USB which has a Windows 8.1 Enterprise .iso and try to reproduce the issue, do we have it?

If not, we know it is one of the applications being deployed.  The next step is to install one application at a time to narrow down further.

For example, we have three applications that are installed as part of post install task sequence. Let us call them:

Application 1
Application 2
Application 3

We install Application 1 and test the behavior. If we do not see the issue, we proceed with Application 2 and so on. If the issue reproduces after we install Application 2, then it is certain that there is some compatibility issue with Application 2. At that point, contact the application vendor for an update or check if it is compatible with Windows 8.1.

A good practice would be to check and make sure that all the applications that are being included are compatible with Windows 8.1. Also, obtain updates for them if they are available.

The issue can be reproduced with only OS installed along with drivers.

In this scenario if using MDT/ConfigMan, does the driver package contain only the drivers for Surface Pro 3 or it has drivers for other hardware too.

As I have already mentioned above, Surface Pro 3 drivers are specifically written and optimized for the Surface Pro 3 device. We often see cases where during deployment a wrong driver is picked and then there are issues post deployment. To make sure it’s not driver related, create a new driver package (if using MDT/ConfigMan) with only Surface Pro 3 drivers and test deployment. The blog I mentioned above gives you an idea on how the folder structure should be for drivers. If you used the blog above to setup your environment then the chances of having issue with drivers are slim.

In case you do not have the structure as mentioned above then, as part of troubleshooting this is what you can do. It is similar to what has be already talked about in the blog above.

Here, I am using MDT 2013 with ADK 8.1 Update installed on Windows Server 2012 R2 Update with WDS.

Create a folder for Surface Pro 3 drivers called “SP Drivers”. You can download the latest driver here.


Next is to create a Selection Profile for the drivers.


Create a new task sequence for deploying Windows 8.1 and modify it to point to the selection profile created above.


Deploy this task sequence and test the behavior.

Device unexpectedly reboots to UEFI screen or hangs are UEFI screen during startup when undocked.

One of the common causes is the incorrect storage driver in use. The correct driver as of writing this is STORAHCI.SYS.


It is also available to download in the Surface Pro 3 driver pack here and is located under folder "..\Surface Pro 3 – January 2015\Intel\SATA_AHCI\".

If you do have machines that do not have the correct controller driver, download the driver mentioned above and update.

Device unexpectedly reboots to UEFI screen or hangs at UEFI screen during startup when docked.

In this case, we undock the machine and see if the issue can be reproduced. If it can, then check the above point for a possible cause.

We also want to remove any external devices connected to docking stating and see if the issue exists.

Is the issue related to Power Management?

When you deploy a customized image, Surface Pro 3 is not configured to hibernate after four hours. This issue is documented in KB2998588 and there is a blogon how to incorporate the commands in MDT.

Surface enters connected standby after 1 minute when PC is locked.

The above scenario is true irrespective of whether device is connected to AC power. Some organizations do not want the device to be entering connected standby or sleep state when Surface is docked. To work around this behavior, configure the device with the Powercfg.exe commands mentioned in KB2835052.

The below commands can be run as part of task sequence.

powercfg.exe /setacvalueindex SCHEME_CURRENT SUB_VIDEO VIDEOIDLE <time in seconds>
powercfg.exe /setacvalueindex SCHEME_CURRENT SUB_VIDEO VIDEOCONLOCK <time in seconds>
powercfg.exe /setactive SCHEME_CURRENT

The VIDEOIDLE timeout is used when the PC is unlocked and the VIDEOCONLOCK timeout is used when the PC is at a locked screen.

clip_image002 Note:

These commands set the timeout used when the system is plugged in and using AC power. To set the timeouts used when on DC (battery) power, use the /setdcvalueindex switch instead of /setacvalueindex.

Then we can change the connected standby / sleep timeout value using Group Policy preferences.

That can be configured using Computer Configuration — > Preference — > Power Options.

Use the Power Plan to control when the device goes to Connected Standby / Sleep using “Turn Off display after” setting:


I hope that this information helps working through deploying Surface Pro 3.

Thank you,
Saurabh Koshta
Support Escalation Engineer