Version 4.x of SysInfo is now available on GitHub. This version has much improved JSON processing and includes additional commands Startapp, StopApp, Shutdown and Reboot. A customisable JSON file is used to list the app commands and their relative URLs. Update Version 4.5 has “Uninstall Package” command.


There are update of this blog for the new version of the OS:


Latest version of the app

Version 4.x of the app is now available on GitHub (see link below). Besides the capabilities of the earlier version (getting system information, network config, installed apps, installed devices etc) this version can start and stop installed packages as well as shutdown or reboot the system. The key configuration of the app is contained in a JSON (ie. text) file that lists all commands along with their web portal relative URL. This url can specify whether POST or GET (the default) is used when sending the REST Request to the portal. This means that, except for specific post processing, the app is simple to extend. Under the hood, the code behind has been substantially improved to make it more general. For example the, processing of the REST Response (text) string is quite generic (can handle any JSON string).


MVP Collaboration

This continues the collaboration between two Microsoft Embedded MVPs, myself and Bruce Eitman. Bruce initially blogged about how to use the web portal  to get the MAC address of a device in the Universal Windows code snippet format (for Windows 10). I turned it into a full UW app that exposed a number of other device properties. Bruce has since posted other how-to code snippets in this area (plus another relevant one) on stopping a running package as well as shutting down or rebooting a device which have been incorporated into this app.  Bruce’s code can be directly copied from his blog posts here on Embedded101. His code and my apps will run on a device or remotely, say, on a Windows 10 desktop. Also, it is possible that given that they are Universal Windows code, they will also run on a Windows 10 phone ( there are some screen trigger resizing issues to resolve here though).


What is the purpose of this app?

This app mimics the web portal to a Windows 10 IoT device that facilitates remote management of a device through a web browser. What is the purpose of this app given that it just implements the same functionality as the Windows 10 IoT Web Portal?

  • Just because we can.
  • The app will run on the device which web portal web page can’t do on the device as it has no Web Browser.
  • You can create custom apps to automate management of the device, or a set devices

The latter point means that you could, for example, start and stop apps on a farm of Raspberry PI2 devices as well as rebooting and shutting them down. Also a later version may expose the remote Appx API enabling remote installation and removal of packages completing the requirements for remote management. Cool eh?

The Take Home

This app shows you how you access various system attributes of a Windows 10 IoT device from a Universal Windows App running on the device or on another Windows 10 device (IoT, Phone or Desktop). The source code exemplifies REST calls and recursive JSON parsing in a Universal Windows context.


Project Source

My Blogs on this topic

Bruce Eitman’s Blogs on this topic


  • The App


(Click-me to expand)

Using the app

For general use refer to my first blog (as above).


The current list of commands is:




























  whatever you enter in its textbox

The URLs are appended to http://<device IPAddress or localhost>:8080/  when creating the HTTP Request.
Note that for the 4 of the last 5 commands, the * indicates to use POST rather than GET ,which is used for all other requests. (the asterix is removed of course).


These commands and their URLs are listed in  the project’s  JSON file: See the JSON file listing here. This file is deployed with the app and so can be modified in-situ and so the app can be extended without modifying its source code.



The last 4 commands on the list above have a confirmation pop-up dialog. The stopapp also has an option to “ForceStop”. These run in a Try-Catch because the pop-ups don’t work on Win 10 IoT. At Universal APIs not functional in Windows 10 IoT Core at this time the API Windows.UI.Popups.MessageDialog is listed as not supported on IoT. I found that you can instantiate the class but it does not function. Certain references with it generate an error, hence the Try-Catch. This means that if you run the Universal Windows app on the desktop you get a confirmation but on the RPI2 it is effectively bypassed. There is though a Checkbox on the Configuration pane to optionally enforce the “ForceStop” for the stopapp command.


Where did these URL strings come from?

These URL strings are gleaned from examining the JavaScript files that are referenced on the Web Portal pages. One script, WebRest.js is listed in full here:


You can also examine what is posted by the Web Portal web page by some network sniffing when a request is made. A simpler way is to enable Developer tools in Internet Explorer (Note that the Edge Web Browser can’t display the Portal ??) . Once you have opened the portal in IE press F12 or get to it from IE settings menu. Here you can examine JavaScripts or capture HTTP Web Requests.


If you select the Debugger tab you can right-click on a JavaScript file and select to show it for examination:


In this case you can see that the URL for getting Packages is api/appx/installed


You can examine the HTTP communications via the network tab:



For example when you select  the Devices tab, amongst the other requests from the web page is:

Name                                                                                Protocol    Method    Result    Content type        Received      Time             Initiator    HTTP    GET         200    application/json    10.47 KB    114.19 ms    XMLHttpRequest

Hence we can conclude that to get a list of devices the URL you need is api/devicemanager/devices


Another Cameo from Bruce Eitman:


Where did those URL strings really come from?


Bruce has pointed out that there is some undocumented documentation on the portal web interface. There is a web page with relevant information on the web portal at http://<the device IpAddress>:8080/RestDocumentation.htm eg:



A sample:

*Task manager/api/taskmanager/start

Starts a modern app



appid : PRAID of app to start, hex64 encoded

Return codes

Success : 200 OK

Error : 500 Internal server error

Error : 400 Bad request



Some experimentation:

If you wish to experiment with these API paths, note that these paths are copied into the box just to the right of the API textbox.
When the [API] button is pressed, whatever path is in that box is used and so you can test any API path you wish. Note also that below the [API] button is another textbox. (Remember to append an asterix to the URL if POST is to be used.) This can be used to add any REST parameters, but it assumed that parameters need to be encoded. Bug: This feature did not work in 4.x but has been fixed in version 5.3 of the app.