Monthly Archives: August 2016

Changing the Start Up App on Windows 10 IoT Core

Changing the start up application on your IoT device running Windows IoT Core seems to be a common requirement once the device is out in the field so I hope this post exploring a few different ways of doing this will be of value to people.

To clarify the behaviour we will achieve below is from device power on our Windows 10 IoT Core operating system will boot up. But instead of starting the default application which is originally named ‘IoTCoreDefaultApp’ we will load our own custom created UWP app executable file. I will not talk about deploying your UWP app to the device, the assumption here is that has already been done and a complied .EXE file is living on the devices local storage.

Application & Package Name

Before diving into any changes it’s worth taking a moment to figure what our UWP application is called. This might seem obvious but depending on how you make this change (via the web portal or PowerShell) it’s referred to by different names. Both are configured in Visual Studio under the Package.AppxManifest and do not have to be the same. See below with screen shots from a new vanilla UWP project.

  • Firstly, the application name which is the friendly display name given to solution on creation and the EXE file presented in the settings web portal.



  • Secondly, the package name which is the not so friendly value (defaulted as a GUID) is used as a prefix for the package family name. This is what PowerShell uses and needs to be exact.


Assumed you’ve navigated that mine field and you know what your UWP app is called depending on the context where its used lets move on.

Headed vs Headless

Sorry, a tiny bit more detail to gain an appreciation of before we actually do this. Start up apps here can take 2x different forms; headed or headless. The difference between them is best thought of as running in the background or running in the foreground. With the foreground apps being visual via the devices display output.

  • Headed = foreground. Visible via display.
  • Headless = background. Not visible, like a Windows service. Also you have no head 🙂

Choose as required and be mindful that you can only have one of each running.

Web Portal

Ok, the easy way to make this change and make your app start up post OS boot: navigate to your devices IP address and authenticate against the web portal. Here in the Apps section you’ll find anything currently deployed to your Windows IoT Core system. Under the Startup field in the Apps table simply click the application you now want to start after the operating system has booted up using the Set as Default App link.


At the point of making this selection the table content will refresh to reflect the change and the application will also start running.

You can now restart you device and your app will load without any further intervention.


Given the ease of the above why would you want to use PowerShell Paul? Well if you’ve got to do this on mass for 30x devices you’ll want to script things. Or, as I found out when Windows 10 IoT Core was still in preview for the Raspberry Pi 3 the App panel in the web portal above had a bug and just didn’t display anything!

Moving on, create yourself a remote management session to your IoT device. If your unfamiliar with doing this the IoT Dashboard can help. Check out my previous blog post Controlling Your Windows 10 IoT Core Device for guidance.

Within the remote management session you’ll need the command IoTStartUp. When using a new command for the first time I always like to add the help switch /? to check out what it can do.

Next work through the following commands in your PowerShell session.

## 1.
## Review the list of apps currently available on your device.
IoTStartUp List
## If your expected app isn't there then it hasn't been deployed to the device.
## 2.
## Copy the package family name from the list or from Visual Studio if you still have it open.
## 3.
## Set the app as headed using the following command.
## 4.
## To confirm which apps are now set for startup use:
IoTStartUp Startup

Here’s the same thing in a PowerShell window just to be clear.


Again to prove this you can now restart the device. From PowerShell use shutdown -r.

Restoring the Start Up Default

To change this back to the default application either repeat the above PowerShell steps for the package family name IoTCoreDefaultApp_1w720vyc4ccym!App or in the web portal set the app name IoTCoreDefaultApp as the default.

Many thanks for reading

Installing Windows 10 IoT Core On Your Raspberry Pi

At a recent SQL Server User Group in Birmingham I presented an end to end IoT solution streaming data from sensors on a Raspberry Pi 3. What followed the talk was a very simple question from an audience member asking basically; how do you get started with doing this? It then occurred to me that I had missed out the vital information for getting the Windows 10 IoT Core operating system (OS) onto the device. In the following article I hope to redeem myself from this error of assumption. This has fallen quiet nicely as well because for the Raspberry Pi 3 the OS only came out of preview a couple of weeks ago. This means you no longer need to be an “insider” to get hold of this.

The SD Card

SDCardVsThumbNo assumptions now, lets be explicit. The Raspberry Pi 2 & 3 require micro SD cards, if your ensure which they are, these are approximately the size of your thumb nail. As well as the physical size the other important thing for Windows 10 IoT Core is you’ll need a Class 10 micro SD card. The class indicates the speed at which you can read and write from the storage, anything less than a Class 10 card will not be fast enough for this OS and it fail to boot up on the device.

In terms of capacity, so far I’ve been working with 16Gb SD cards without any issue or limits on storage. As you’ll see below once the card has been imaged is gets partitioned and on a 16Gb card a chunk of that is left unallocated.

Lastly to get the micro SD card available in your Windows desktop machine I use the following adaptors which have served me well for many years. All the micro SD cards I’ve purchased have always come with the standard SD card shell and are only pence to purchase separately if required. The final USB reader is just in case the machine doesn’t already have such a thing. All my laptops have a slot on the side, but not my desktop machines.


IoT Dashboard

Assuming you now have the right size, shape and smell of SD card available in Windows by far the easiest tool I found to flash the card is Microsoft’s IoT Dashboard. This is available to download and install from here: Helpfully the IoT Dashboard is a ClickOnce install and frequently receives updates to it’s options.

On the ‘Set Up A New Device’ panel you have everything you need to install the Windows IoT Core OS image on your card.


After selecting your required combination of board you can even now configure the hostname and admin password for the target device. Something which previously had to be done post install with PowerShell or via the settings web portal. See my previous blog post on controlling your device if you require assistance with this >>>.

Next you just need to accept the usual T&C’s and flash the card. If your chosen OS image hasn’t already been downloaded this will also be done for you as well. Lovely!

Note; elevated permissions will be required when the process comes to partition and write to the card so expect a prompt if you aren’t already a local administrator.

After the process has completed I’d strongly recommend a safe eject of the device via normal Windows methods to avoid any corruption and ultimately needing to repeat the process.

You can now insert the card into your Raspberry Pi and boot it up.

Disk Management & Card Contents

This is just extra information should you be interested in what the IoT Dashboard imaging process did to your SD card. I was certainly concerned to discover that Windows now thought my SD card was only 64Mb in size after the flashing processes!

In Windows Disk Management you will now have something that looks like the following. As mentioned above the card actually gets partitioned with only one of those partitions being a FAT file system that Windows can read and present.


To further confuse things if you boot the device and mount the admin share C$ from a UNC path of the IP address as a mapped network drive it’ll appear like you have accessed the 1.31Gb block of the partitioning. Here your Windows desktop machine will probably report something like 571Mb of the space at the network location has been consumed. So far so good right?


But, if you enter the mapped drive Select All and Right Click > Properties you’ll then find files and folder totally 1.57Gb!


The shortcuts you see in the above screen shot for ‘CrashDump’, ‘Data’ and ‘EFIESP’ report the target as an “Unlabelled Volume” if you view there properties. But you can navigate to them and browse the contents.

In an attempt to work out what folders physically existed where on the SD card I took a random 2Gb ISO file and started copying it into different directories. Sadly this led to even more confusion. The only thing I think we can be sure of is that the ‘Data’ shortcut above represents the 12.86Gb partition seen in Disk Management. But even that I didn’t manage to prove because it contains a nest of other Program Files directories as well.

In conclusion we might have a 16Gb SD card, but finding out what the operating system has used and what we still have available for apps or camera pictures remains a mystery for another day.

Many thanks for reading

Paul’s Frog Blog

This blog is now closed to new comments or posts.

Please see new posts here