v1.1.0.1 release notes

Update 1/29 7pm - Version is now in the Store.

Version of Digital Prism was submitted to the Store on 1/28. After certification finishes in a couple days and it is published to the Store, Windows will automatically install the new version. You can also manually update it by going to the Store.

Version has two fixes in it:

  • Crash on app launch for PCs with multiple network adapters
  • Layouts updated for 768 vertical resolutions

Crash on app launch

There was a nasty bug that causes Digital Prism to crash immediately when you launch it. This bug affects some PCs that have more than one network adapter (for example, both a wired and wireless network adapter). This bug manifests when Digital Prism searches for the Hue Bridge on an invalid adapter. If you have multiple network adapters (physical or virtual), you may have hit this.

In v1.1.0.1, the network adapter that your Internet connection is active on is searched for a Hue Bridge.

Updated layouts for 768 vertical resolutions

I do most of my testing on my Dell Venue Pro 8 which has a 1280x800 resolution. If you are using a 1366x768 PC (like a Surface), some of the controls are cut off at the bottom.

In v1.1.0.1, the layouts for these controls now work with 768 vertical resolutions.

If you're curious...

I noticed the app crash on launch bug when I installed Digital Prism on my work PCs. This bug didn't come up while testing on my personal PCs.
After panicking when I saw the app crash, I checked Event Viewer to see what was going on. I saw this error:
Faulting module name: twinuiapi.appcore.dll Exception code: 0x000027b

After some intense Binging, I was fortunate enough to find a post where somebody said they hit this and it was related to networking. Sure enough, when I turned on airplane mode, the app didn't crash on launch. I narrowed the crash down to this part in my code (SSDP discovery of the Hue Bridge):

await socket.BindEndpointAsync(null, string.Empty);
var stream = await socket.GetOutputStreamAsync(multicastIP, "1900");

Catching the exception got me no such host is known. Some more searching got me to this post which says that the order in which LUIDs for adapters is generated is "unpredictable." The root cause then is that on PCs with multiple network adapters, the socket was bound to an invalid adapter (but not necessarily a disconnected adapter). I'm not sure which configurations are worse than others, but some of my work PCs always hit the isssue. These tended to be laptops with virtual adapters (for VMs), bridged adapters, Direct Access, and wired/wireless adapters.

The fix, then, is to explicitly bind the socket to a network adapter that is known to be valid. For the time being, I'm using the adapter that has an active internet connection as that is a pretty safe bet. If you're the tinfoil hat type with only a LAN (but no Internet) - you will have to wait until a later version of Digital Prism where I fall back to other active connections if an internet connection is not found.

Old code:

var multicastIP = new HostName("");
await socket.BindEndpointAsync(null, string.Empty);

New pseudo code (connectionProfile should be checked for null):

var multicastIP = new HostName("");
var connectionProfile =              NetworkInformation.GetInternetConnectionProfile();
await socket.BindServiceNameAsync("", connectionProfile.NetworkAdapter);