locked
WinRT MIDI stack name handling flaw. WinRT MIDI stack is presently unusable. RRS feed

  • Question

  • The WinRT MIDI stack appears to have a serious name handling flaw that manifests a number of issues.

    Here are a few examples of enumerated device names:

    Oxygen 25 [0]
    Oxygen 25 [1]
    A-01 [0]
    A-01 [1]
    Launchpad S [0]
    Launchpad S [1]
    QUAD-CAPTURE (1)
    Boutique (1)

    The device names that end in [0] are for output, and the device names that end in [1] are for input.

    The device names above that end in (1) are for input and output, yes, that little detail is also problematic.

    But it gets worse.  Any device that has a consolidated name for input and output, that is, it does not have a [0]/[1] ending to its name, those ending in (1) above, hang the MIDI stack when any given SysEx message is sent to its output port.  The GUI of the associated App also becomes frozen.

    I'm speculating; the lock up is probably due to the fact that the MIDI stack has confused itself as to where to send the output due to this naming inconsistency.  So devices that have a consolidated name for input and output hang the MIDI stack when a SysEx message is sent, and the only method of recovery is to sign out or restart.  Closing the UWP apps process does not clear the problem.  Closing an app should always clear up any such problems and not result in a hung IO stack.

    Device names should either always be consolidated, that is, there should never be a [0]/[1] ending to the name, or they should always have the separation.

    So at present, the WinRT MIDI stack is unusable because of the lock up when sending SysEx messages to devices that have a consolidated name.

    Looks like Microsoft needs to have a better testing regiment here.  If Microsoft chooses not to fix the naming issue, that's fine, we can work around the inconsistency.  But the MIDI driver layer has to work with the naming variations correctly.

    This problem needs to be resolved ASAP!!!

    Sunday, April 30, 2017 2:49 PM

All replies

  • Using the following code to get Manufacturer ID:

    var data = new byte[] { 0xF0, 0x7E, 0x7F, 0x06, 0x01, 0xF7 }; midiOutputDevice.SendMessage(new MidiSystemExclusiveMessage(data.AsBuffer()));

    This code causes the Win10 Store App to lock up and hang the MIDI stack when executed against any of the Roland gear I have (the entire Roland Boutique line, the entire Roland Aira line, and the Roland A-49 keyboard controller, etc.).

    The same request works as expected from a Win 10 Win32 application with the same dozen or so of Roland devices.

    The same code works as expected for both Win 10 Store and Win32 Apps when using non-Roland gear, such as the Novation Launchpad. You can try this with the Microsoft UWP MIDI Basics sample app. I'm guessing the code hangs with any Roland gear that has a native Windows 10 driver.

    There appears to be something wrong under the hood with Roland gear and the Win10 Store MIDI API. I've noticed that for all the Roland gear I have (entire Boutique line and Aira line), a driver is pushed onto the system when the USB device is plugged in.

    This problem has completely stalled my ability to release a Windows Store App that is a patch editor / control surface for the above Roland products.



    • Edited by noemata Saturday, April 29, 2017 12:24 AM
    • Merged by Barry Wang Monday, May 1, 2017 9:39 AM same issue
    Saturday, April 29, 2017 12:21 AM
  • As a follow up to the above, after investigating this further and trying to find a work around I have found the following additional issues.

    When using the following code pattern, the Apps GUI becomes hung after the SendBuffer call. We do get the Manufaturer ID returned to the OnMessageReceived handler, and the handler continues to get fired even though the GUI is hung.

                        GlobalVariable.MidiInputDevice.MessageReceived -= OnMessageReceived;
                        GlobalVariable.MidiInputDevice.MessageReceived += OnMessageReceived;
                        // Get Vendor Id for port.
                        var data = new byte[] { 0xF0, 0x7E, 0x10, 0x06, 0x01, 0xF7 };
                        IBuffer buffer = data.AsBuffer();

                        GlobalVariable.MidiOutputDevice.SendBuffer(buffer);

    With the following code, the GUI is no longer hung, but MIDI IO to the associated device is blocked until the current windows session is ended with a sign out or restart.  Ending a user level process should resolve such issues so this is a serious problem.  Given this all works under Win32, clearly the UWP/WinRT side of things is somehow broken.

                    midiInputDevice.MessageReceived -= OnMessageReceived;
                    midiInputDevice.MessageReceived += OnMessageReceived;

                    // Get Vendor Id for port.
                    var data = new byte[] { 0xF0, 0x7E, 0x10, 0x06, 0x01, 0xF7 };

                    var backgroundThread = new BackgroundWorker();
                    backgroundThread.DoWork += (_, __) =>
                    {
                        midiOutputDevice.SendMessage(new MidiSystemExclusiveMessage(data.AsBuffer()));
                    };
                    backgroundThread.RunWorkerCompleted += (_, __) =>
                    {
                    };
                    backgroundThread.RunWorkerAsync();

    Note: you'll need to try this with any of these: JU-06, JP-08, JX-03, TR-09, TR-8, System-1, System-1m, System-8, MX-1, etc. in other words any fairly recent Roland product.




    • Edited by noemata Sunday, April 30, 2017 12:21 PM
    Sunday, April 30, 2017 12:08 PM
  • Trudging around I noticed this posting: 

    https://forum.juce.com/t/experimental-support-for-the-windows-runtime-midi-api/21049

    "2) Sending or receiving sysex messages is very likely to cause a hang."

    Sunday, April 30, 2017 6:21 PM
  • I was able to confirm that this problem affects any vendor's product (tested with Yamaha, Korg and others) where the device name has a consolidated name for both input and output, that is, the name does not have a "[0]" / "[1]" suffix for the device name where the device supports both MIDI input and output.

    So this problem has nothing to do with Roland, Yamaha or Korg native Windows 10 drivers, but is a manifestation of a flaw in the Windows 10 WinRT MIDI stack and is probably related to the inconsistency in name enumeration.

    Windows 10 Win32 MIDI functions correctly.

    Where device names have a "[0]" and "[1]" suffix, WinRT MIDI SysEx calls work correctly.

    I appreciate the benefit of having the [0]/[1] suffix, but it is only useful if the convention is applied consistently across devices.  The added noise in device names and the fact that it is a different strategy from Win32 make this clever idea less so.

    There are also instances where the device name is radically different from the Win32 equivalent?

    • Edited by noemata Sunday, April 30, 2017 10:34 PM
    Sunday, April 30, 2017 10:14 PM
  • Hello noemata,

    What version of the OS are you seeing this issue on? I looked in our issue tracker and it looks like we fixed a couple of issues with sysex messages in the Anniversary Update and it looks like we have a couple that have been reported by the community. Its hard to say if they are related.

    https://aka.ms/gx3nmn

    https://aka.ms/t2x4qe

    I'm going to see if I can scrounge up some MIDI hardware but I'm likely not going to be able to find the necessary hardware in the lab to reproduce the issue. I have some at home that I will bring in and see if I can reproduce the issue. But the fastest and easiest way for me to investigate is for you to generate a dump file when the app is hung, zip it up and put it on your OneDrive. Post the link here and I will grab it and take a look. If you aren't comfortable with putting a dump file for your sample app on your OneDrive please open an engagement with my team and I'll take a look at it for you.

    https://developer.microsoft.com/en-us/windows/support

    Thanks,

    James


    Windows SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Tuesday, May 2, 2017 1:11 AM
  • Winver reports the OS's I'm testing with as:

    Version 1607 (OS Build 14393.1066)

    and

    Version 1703 (OS Build 15063.138)

    I received an access denied message navigating to the links you provided.

    As for duplicating this problem, all you need is a MIDI device that has a name that does not end in "[0]" and "[1]" and supports both input and output.  I suggest you use one of the devices ending in "(1)" that supports both input and output.  I have several from Roland, Yamaha and Korg.  Roland is your best bet, since their native Windows 10 drivers are the most conformant and also happen to be pushed through the Windows 10 update process, so all you have to do is plug their device in.  Just make sure the device does not have a [0]/[1] suffix as a handful of Roland products do and will thus work correctly (e.g. Roland's A-01 works correctly, the Boutiques do not).

    I'm pretty sure Microsoft's lab will have at least half a dozen such devices, unless all your gear is older than 4 years.

    Could you please provide some detail on how to generate the dump file for the sample app.  I presume the dump file is restricted to the memory space of the sample app?

    Thank you!

    Tuesday, May 2, 2017 2:28 AM
  • I reported the problem of not being able to send Sysex messages over two years ago. I also concur about the MIDI port name enumeration, for many MIDI drivers the port enumeration is wacked. If Microsoft expects music and music app creators to take their OS seriously, they really need to fix issues like this. 

    Tuesday, May 2, 2017 6:56 PM
  • Winver reports the OS's I'm testing with as:

    Version 1607 (OS Build 14393.1066)

    and

    Version 1703 (OS Build 15063.138)

    I received an access denied message navigating to the links you provided.

    As for duplicating this problem, all you need is a MIDI device that has a name that does not end in "[0]" and "[1]" and supports both input and output.  I suggest you use one of the devices ending in "(1)" that supports both input and output.  I have several from Roland, Yamaha and Korg.  Roland is your best bet, since their native Windows 10 drivers are the most conformant and also happen to be pushed through the Windows 10 update process, so all you have to do is plug their device in.  Just make sure the device does not have a [0]/[1] suffix as a handful of Roland products do and will thus work correctly (e.g. Roland's A-01 works correctly, the Boutiques do not).

    I'm pretty sure Microsoft's lab will have at least half a dozen such devices, unless all your gear is older than 4 years.

    Could you please provide some detail on how to generate the dump file for the sample app.  I presume the dump file is restricted to the memory space of the sample app?

    Thank you!


    Virtual MIDI ports such as LoopBe exhibit this problem also.
    Tuesday, May 2, 2017 7:08 PM
  • I have re-run my tests against 7 different PC's which included variations of laptop, desktop and tablet PC's, and found 19 different failing MIDI devices spanning synths, controllers and audio interfaces from three different vendors.  Of the gear I have in my lab, over 50 percept of it experienced the hanging problem.

    Any device where it's name had a "(1)" suffix in its device name and where the device supported both input and output would experience this hanging problem when any SysEx message was sent to the device from a UWP App.

    Desktop (Win32) applications that used the same UWP API worked correctly!

    UWP Windows Store Apps worked correctly with devices that had a "[0]" / "[1]" suffix in their device names!

    At this point I feel my statement that the WinRT MIDI API is unusable is fair in the context of a Windows Store UWP App.  For a Store App, you have a very high chance of hitting this issue if you need SysEx control of your devices.

    Note, if you do not send out a SysEx message, the UWP API works very well and is in many ways superior to the older API because of the level of abstraction it provides.

    Please fix this.

    Wednesday, May 3, 2017 2:59 PM
  • Hi Everyone,

    Sorry it took me so long to respond. //build is upon us and taking up everyone's time.

    I did look into this and I see that Matthew did investigate Jim's report. His analysis shows that the problem was likely due to the LoopBe driver waiting on an outstanding completion handle from an async call to DeviceIoControl. It was determined that this is likely due to a deadlock in the LoopBe codebase. The report does suggest that we passed this on to LoopBe.

    That said, the fact that it affects so many different devices including hardware based devices is very worrying. Would someone please generate a dump file when the app is in the hung state when using a hardware device. In fact, if you can generate a couple of dumps with different hardware devices I would really appreciate it. That way I can correlate between the two devices and make sure we are seeing the same code path for each. Please zip up the dumps, put them on your OneDrive and paste a link here. I'll take a look at the dumps and see if I can figure out what is going on.

    Thanks much,

    James


    Windows SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Thursday, May 11, 2017 12:30 AM
  • I have been informed by four separate Microsoft staffers that this was a known issue.  Two of these staff members are definitely in the know given the sort of work that they do, namely Pete Brown and Dale Stammen.  There is something eerily disingenuous about the way this particular problem is being handled.  Do you folks talk to one another?

    If you cannot accept that most recent Roland, Yamaha and Korg gear does not work under WinRT assuming you accept the premise that SysEx calls are critical, I have to question how you folks actually go about testing things?  I wound up taking a really good look at this problem and have discovered this has not been dealt with since Windows 8.1 based on feedback from the very small number of developers pushing on the edges of the WinRT MIDI API.

    I literally begged Pete Brown to do what he could to sort this out and was told the issue would not be resolved until sometime this fall.  So I guess 2014 to 2017 is an acceptable period of failure for Microsoft.  Obviously Microsoft can absorb such losses.  In the bigger scheme of things the WinRT MIDI API is not particularly important or noteworthy given how little use or attention it has received.

    That said, the WinRT MIDI API will wind up as the WinRT API Canary in the Coal mine if it is not attended to.  Let it die and Windows 10 S will die with it, just like WinRT MIDI apps have been dying.

    I've reported several fairly serious bugs with the WinRT API, and in most instances all I get is push back.  I have had to let go of two contractors that were helping me with this.  So now, the hundred or so developers in Toronto that are working on UWP apps are reduced in ranks to 98 and I wouldn't be surprised if my estimate is excessively generous.

    There is a good reason the WinRT API ain't happenin'.  It's buggy in key areas, keeps changing arbitrarily, and has demoralized or bankrupted the developers that tried to invest in it because of Microsoft's in fighting, constant reboots, and push back.

    I don't really get it.  The design is good, the premise is solid, the investments have been substantial.  What gives?  WinRT seems to have an existential crisis, perhaps even a death wish.

    Lastly, Build 2017 may seem like a good excuse to you, but you might as well kick sand in my direction mentioning Build here.  I have invested big in this and will be totally screwed by the fall.  I would welcome having David Dao's bloodied mouth and nose over this due to my kicking and screaming.  In fact if Microsoft wants to send a couple thugs to Toronto to beat me up, that would be ok by me provided you fixed this.  The financial pain I'll be experiencing by the fall will be far worse than a bloodied nose or broken arm.

     

    • Edited by noemata Thursday, May 11, 2017 3:09 PM
    Thursday, May 11, 2017 4:12 AM
  • Hi noemata,

    Thanks for letting me know that you spoke with Pete and Dale. While I don’t know them (there are over 35,000 MS employees in Washington State alone) I was able to find the code defect report they filed on behalf of your organization.

    The report is currently assigned to the developer that owns the MIDI APIs. He is actively investigating the issue.

    My concern at this time is that the report only tangentially mentions the SysEx issue and is focused on the bad device names being enumerated (that’s is the reason I was unable to find it previously). We need to get both investigated and fixed. I’ll talk with the API owner and make sure he is aware of the SysEx issue as well.

    -James

    Windows SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Friday, May 12, 2017 11:55 PM
  • It's good to see some action on this. On the topic of the device naming problems: I also exchanged emails with Pete Brown concerning problems with the port names that the API was enumerating for Tobias Erichsen's loopMidi virtual MIDI ports. Tobias is the creator of the very popular rtpMIDI network MIDI driver. I know that Pete and Tobias conversed and some contact was made with a development group within Microsoft. I would be good to see if this was ever resolved or if someone is looking into it. The port naming problem was creating a lot of issues with my app, as the ports all had the same name.
    Saturday, May 13, 2017 12:16 AM
  • Hi Jim,

    Thanks much for the additional info. I've reached out to Pete & Dale to get some additional context and to see how I can drive this forward.

    I'm an electronic musician and MIDI enthusiast myself. I guess I have a personal interest in helping the MIDI community be successful on the UWP platform :)

    I'll keep you up to date.

    -James


    Windows SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Saturday, May 13, 2017 12:37 AM
  • I was able to work around some, though not all, of the enumeration problems by ignoring the enumerated device name and using the device id instead.  I don't want to post the work around here because this issue really should be fixed, and posting a work around may actually delay getting a fix.

    With the work around, Erichsen's loopMidi works well with the exception of SysEx messages which fails for any MIDI device that does not have a "[0]" / "[1]" suffix in the device name so the SysEx problem is not specific to any vendor's driver.

    Pete Brown is the public face of Audio/Midi for Microsoft.  He's the very nice guy that most folks are likely to bump into when contacting Microsoft about this tech.  Dale Stammen is the equally nice fellow that worked with Cakewalk to develop a WinRT wrapper API.  Cakewalk is one of the oldest and most prominent consumers of these API's.

    I guess James doesn't get out much ;-)

    Saturday, May 13, 2017 12:43 AM
  • Hi All,

    Just a quick update to let you know that I'm continuing to track this and pushing for a fix (although I give no guarantees). We are tracking this as two separate issues. The enumeration issue and the SysEx hang issue. The two defect reports are linked as they do appear to be related. The defect reports have been assigned and the investigation is ongoing.

    I'll report back when I know more.

    Thanks,

    James


    Windows SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Friday, June 16, 2017 9:08 PM
  • It would be very helpful to get an ETA for the resolution of this issue.  Windows 10 S has inherited this bug.  For Windows 10 S, the fix is even more important given that there is no alternative to the UWP MIDI API.
    Wednesday, August 2, 2017 12:40 PM
  • Pete Brown, Bala Sivakumar, James Dailey, Matthew van Eerde, Rob Caplan: Will this bug ever get fixed?
    Saturday, December 9, 2017 3:33 PM
  • James, thanks for the updates, it's comforting to know that someone on the inside is tracking these issues. However, your last update was 6 months ago, has there been no progress in resolving these issues? Please reassure us that the ball has not been dropped. :)

    Cheers
    Eddie

    Wednesday, January 10, 2018 11:12 PM
  • Hi Eddie,

    Thanks much for following up. I can assure you that there is an open work item for this issue. It is currently assigned to a developer and a possible fix for the issue is being considered.

    I wish I could give you an exact timeline but I would recommend that you keep an eye on the insider builds. Most of the time (although not always) fixes for the next version of the OS are added to these builds.

    That said, I've updated the work item to remind the team that this is still a critical issue for the MIDI community. I'll will continue to track the work item. Once I know anything concrete I will absolutely let you know.

    Thanks again,

    James


    Windows SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Thursday, January 11, 2018 12:25 AM
  • James, thanks for the update and reassurance, I sincerely appreciate it.

    I will definitely keep my eye on the insider builds and this thread.

    Thanks again.


    Cheers
    Eddie

    Thursday, January 11, 2018 1:32 AM
  • Preview Build 17093 was announced today.

    There is no mention of fixes for the MIDI enumeration and system exclusive message issues.

    Here's hoping the next build will have something.


    Cheers
    Eddie

    Thursday, February 8, 2018 3:46 PM
  • Preview Build 17093 was announced today.

    Beware of that build. The start menu isn't working for many (including me)!

    There is no mention of fixes for the MIDI enumeration and system exclusive message issues.

    Only certain bugs/fixes get mentioned, so you can never be sure.

    Dave

    Thursday, February 8, 2018 5:08 PM
  • Hi All,

    I just wanted to offer a quick update on this. We have been actively investigating the issue. Unfortunately a fix has proven to be a bit more complex than expected. We continue to investigate possible resolutions to the problem.

    I will stay engaged and post here as the investigation continues. 

    Thanks for your patience,

    James


    Windows SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Thursday, March 8, 2018 12:05 AM
  • I will stay engaged and post here as the investigation continues.



    Thanks a lot. I appreciate you keeping us updated, even if the news is not what we would like to hear.

    Cheers
    Eddie

    Thursday, March 8, 2018 1:27 AM
  • The "actively investigating" sorts of replies are more than a little disingenuous at this point given we've been waiting for some sort of resolution since at least 2015.  That's now 3 years ago!  James, this problem really isn't that complicated.  The only thing complicated seems to be the process Microsoft uses to hire qualified staff to work on critical Windows infrastructure components.

    And if this sounds harsh, being on the receiving end of OS deficiencies such as this is even harsher when you discover your hard work has been invalidated by dysfunctional Microsoft OS components making it impossible to make a profit with a given software initiative (unless you don't care about lying to your customers).

    Please just get on with it and fix this before there are more defections to other platforms.  Microsoft is no longer the only show in town, and you're killing off your Microsoft loyalists with this sort of BS.

    Thursday, March 8, 2018 5:19 AM
  • Hi James,

    I have been looking everywhere for someone who would at least acknowledge these issues, so thank you for that. When the new API was released, we were promised low latency and multiple connections per device, something that wouldn't be available in the "legacy" API (aka the only usable one). Unfortunately, it takes time for existing apps and libraries to upgrade, so even if the new API worked today, it could still take several months to get support in apps used every day by countless musicians, producers, audio engineers, etc. This is why I believe it is critical that this gets addressed as soon as possible.

    For my part, I am trying to create software for more flexible MIDI control scenarios - things like touch screens and cameras which are built-in hardware don't create their own MIDI ports even though they have potential to be used that way with the right software. I really need the ability to create virtual ports for this, because MIDI is the one protocol common to all music production apps. I was using rtpMidi, but I was getting extremely frequent crashes until I disabled it. I want to impress that other platforms have had this ability for years, and if you browse through GitHub you'll see tons of interesting MIDI projects using Arduino and Raspberry Pi. The demand is there, it's just the functionality in Windows that is not.

    I hope that you can pass this along to someone that can reprioritize this. I thought the Surface hardware had a ton of potential for interactive music creation, but I've lost so many hours researching if that was even possible. The fact that it isn't is a huge oversight on the importance and usefulness of MIDI to music creators. Please encourage the audio teams to re-evaluate, look closer at the music and music-related developer communities, and provide us with a solid foundation to use the hardware to its full potential.

    For the desktop, while lack of virtual ports and locked connections are frustrating, the old API is passable. I could never consider a UWP-only device though while these problems remain, and I will encourage other musicians to look elsewhere as well until we get good solid MIDI support. Hoping this will change soon.

    Thursday, May 3, 2018 9:17 PM
  • Hi All,

    I just wanted to jump in and offer a quick update. We've been able to address a number of MIDI issues in resent builds. More fixes are coming in the next update.

    The issue at the subject of this thread (ambiguous MIDI device port names) has been very problematic. Various fixes have been proposed. Its a fundamental change so more testing is required before we can commit. 

    I'll continue to monitor the work item and keep everyone up to date.    

    Thanks,

    James


    Windows SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Friday, June 15, 2018 10:46 PM
  • Thanks for the update James.

    It's a relief to see a report of some progress being made.


    Cheers
    Eddie

    Saturday, June 16, 2018 12:22 AM
  • Hi all,

    Thought I'd jump in here since I just encountered this naming problem. My Roland ports (UM-3G) are all naming correctly, though appended with a (1). My Yamaha ports (MU2000, 1-in 8-out) are all simply named "MIDI". I was looking for a fix (though I suspect the outdated driver just doesn't play with the WinRT inquiries) which led me to this thread, which led me to the SysEx problem. A hugely necessary component of my program, I had to test it myself because if it doesn't work, I'd have to rewrite for Win32.

    On Windows 10 v1803, I'm definitely getting hanging from sending SysEx messages. However, they're sending properly, and I'm successfully receiving a response (Identity Request/Response). I did a little Googling and discovered a JUCE forum post that makes mention of these same issues. It seems this SysEx problem only really pops its head up for small messages ("shorter then [sic] 19 bytes"). Padding my identity request with a bunch of zeroes, up to about 23 total bytes, still hangs. But I added a few more, about 32 now...

    Success! SysEx seems to be sending smoothly!

    Here is the original JUCE post if anybody wants to look at it: https://forum.juce.com/t/experimental-support-for-the-windows-runtime-midi-api/21049

    It also mentions problems with long buffers, but I haven't really checked that out yet. Hopefully that's just a JUCE thing.

    Cheers,
    Ashley


    EDIT: Just noticed above that noemata found this same post. Just, a bit too soon by the looks of it.
    • Edited by c4ashley Wednesday, June 20, 2018 8:29 AM
    Wednesday, June 20, 2018 8:26 AM
  • Hi Ashley,

    Thanks for jumping into the discussion. We are also aware of the issue with short SysEx messages hanging and are working on that one as well. I really appreciate that you've shared your workaround of padding out the request. Great to know that it is working for you! 

    Thanks again,

    James


    Windows SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Wednesday, June 20, 2018 5:12 PM
  • I updated to 1809 (build 17763) and SysEx messages that locked up my UWP app before are now working successfully. Huge relief!

    Has anyone else tested 1809?


    Cheers
    Eddie



    • Edited by Eddie Lotter Saturday, October 6, 2018 4:49 PM Additional info.
    Saturday, October 6, 2018 4:46 PM