The OPC.Ua.SampleServer OnLaunched() method timtedout on Rasphberry Pi 3 about ua-.netstandard HOT 27 CLOSED

Hi @wagmannj , Just curious to know which coreclr distribution you use on the RPI3. Looks like the coreclr on ARM is not yet published by Microsoft. Did you compile it yourself from the GITHUB repository or is there a beta version somewhere?

from ua-.netstandard.

Hi,
I am useing the last version of Windows IoT Core Insider Preview Build 14393 on RPI3.

from ua-.netstandard.

I think he means the UWP server sample app. It sounds like the async Application.OnLanched() method may be deprecated in the "Anniversary Edition" (i.e. build 14393) of Windows 10.

from ua-.netstandard.

Trying this out on a desktop build of "Anniversary Edition" (i.e. build 14393) of Windows 10 doesn't repro the issue, however. Perhaps a bug in the Windows IoT Core preview build. Investigating...

from ua-.netstandard.

Hi,
now, i am trying out on a desktop with anniversary edition. its run well. On RPI 3 with Windows IoT Core preview the the async OnLaunced() method will be aborted by the systems after a certain time. This behavior does not show when the appliation is running under debugger control. May be a feature or a bug in Windows IoT Core? Thanks.

from ua-.netstandard.

That's what I'm thinking, too. I'm in contact with the Windows IoT Core team about this already...

from ua-.netstandard.

Hello! I'm on the Windows IoT Core team and am looking into the trouble you're seeing ... unfortunately, with my setup, I'm not seeing the issue you are. I've tried the ServerSample with and without the debugger and haven't seen any problems.

I'd like to know what to specifically watch for ... how does the break manifest? (does an exception show up somewhere? is there a dialog that shows up? etc)

Can you provide any more details?

• any changes to the project or code from what is in git?
• what is the full version string you see in IotCore ... 10.0.XXX.YYY?
• what version of Windows do you have running on your development machine?
• what version of Visual Studio do you have installed? (can be found in Help > About Visual Studio)

from ua-.netstandard.

• No chanches to the Project Code
• Device Name: minwinpc; Device Model: Raspberry Pi 3; OS Version: 10.0.14393.67
• Windows 10, Version 1607 (Build 14393.105)
• Microsoft Visual Studio Community2015, Version 14.0.25425.01 Update 3
• I start the Application from the App Manager Page (Device Portal)
• There are no exeption or error message in the log file (....AC/temp/opc......) but its not complete. My
  guess. there is no reference of the running Application.OnLanched() thread and the garbage
  collector release the thread before its finished. If you insert a 20 second delay before the call "await
  application.Start(new Opc.Ua.Sample.SampleServer())" its break after wait();

My modificaton:
OnLaunched.txt

from ua-.netstandard.

Thanks for the info! A few more questions ... are you creating a Debug or Release build? How are you deploying (building an APPX and using the Device Portal, using Visual Studio deploy, some other way)?

from ua-.netstandard.

I create a Debug Version and using Visual Studio to deploy it.

from ua-.netstandard.

I haven't been able to reproduce this issue as you've encountered it (F5 from Visual Studio just works, and once the app is deployed, running it from the Device Portal works as well) ... the closest I've been able to come is by replacing the await/async calls in OnLaunched with Task.Result calls. For example: var result = application.LoadApplicationConfiguration(false).Result

Doing that seems to lead to the ServerPage not being displayed before the call to application.CheckApplicationInstanceCertificate(false, 0).Result ... when that happens, the call to CheckApplicationInstanceCertificate blocks for me, waiting for a MessageDialog to be closed (which isn't shown because ServerPage hasn't replaced the Splash screen). That seems to be the same symptom that you are seeing, but I have on idea if it is the same issue (unlike your issue, what I'm seeing occurs on local machine as well as IotCore).

I'd be curious to know if you put more Util.Trace calls into the code, (add some more to OnLaunched, CheckApplicationInstnaceCertificate, etc) just where things stop executing for you.

from ua-.netstandard.

Thanks, i have inserted some log entries. After inserting a delay call the execution is stopped before the second log. One time i see in the browser (edge) that the application can't start.

Opc.Ua.SampleServer.log started with debugger.txt
Opc.Ua.SampleServer.log started from App Manager.txt
OnLaunched.txt

from ua-.netstandard.

I just noticed that this project is using .NET Core (I see this command in my build window: C:\Program Files\dotnet\dotnet.exe build). I don't know what their progress is related to IotCore on ARM. But ignoring that for the moment...

When you add the 20 second delay to the OnLaunched handler, it looks to me like the App activation is timing out. This is a problem when the App initialization takes a long time. I'm not sure whether that explains your general issue or not, without the delay, did the app stop or did it just never start the server?

Something I tried was moving the server initialization away from the app initialization code:

ServerPage.xaml

<Page
    x:Class="Opc.Ua.SampleServer.ServerPage"
    . . .
    GotFocus="Page_Loaded">
    . . .

ServerPage.xaml.cs

private void Page_Loaded(object sender, Windows.UI.Xaml.RoutedEventArgs e)
{
    if (m_application == null)
    {
        ApplicationInstance.MessageDlg = new ApplicationMessageDlg();
        m_application = new ApplicationInstance();
        m_application.ApplicationName = "UA Sample Server";
         . . .
}

For me, that worked both under the debugger and from the Device Portal (the log in both cases showed the server starting).

from ua-.netstandard.

I suspect a timeout for some time in the asynchronous onlaunched method. 'However, i have no error message found in the log or a indication in the functional documentation. If i don't add some delay in the code is abortet on different places.
Do you see that the process opc.ua.sampleserver is listening on the port 51120 after startup?

from ua-.netstandard.

I agree that it looks like a timeout is happening. I'm curious to see whether it is a timeout garbage collection in an async OnLaunched or whether it is a timeout in the app startup.

When you see the timeout situation, do you see any evidence that the app is still running? Does it show up in the App list as running in the Device Portal:

Or does it show as an app that is not running:

from ua-.netstandard.

After a short time the symbol in the device portal is switching from a square (running) to triangle (inactiv). In the process, dumped with powershell get-process the opc.ua.sampleserver isn't listed.

from ua-.netstandard.

OK. That probably means that the OS's app model framework is determining that the app is timing out on startup. Is that behavior consistent when you do not have the delay in OnLaunched?

from ua-.netstandard.

Yes, it is consistend when i don't have a delay in the OnLaunched. Is this a standard behavior?

from ua-.netstandard.

I believe it means that the synchronous OnLaunched method is delaying the Apps feedback to the OS that it has started successfully. The OS then decides to kill the App as it (the OS) believes the app to have hung.

The timeout behavior is common behavior to Desktop, however, the Pi doesn't quite have the computational power that Desktop does (because of this, we've added extra time for IotCore to allow for our slower processors).

For IotCore, it is better to avoid much synchronous code in the App initialization.

from ua-.netstandard.

The synchronous OnLaunched method is well, the async method timed out. Oh, a new Windows 10 IoT Core version is arrived. I reboot and test it with the new version.

from ua-.netstandard.

After restart the OS version is OS Version: 10.0.14393.187. The game is the same, synchronous OnLaunched method is well, the async method timed out.

from ua-.netstandard.

I tried coming at this from another direction. I was curious as to whether .NET Core (vs standard UWP) was the issue.

I created a new C# UWP project and modified

App.xaml.cs:

        protected override async void OnLaunched(LaunchActivatedEventArgs e)
        {
            var page = new MainPage();
            Window.Current.Content = page;
            Window.Current.Activate();

            await DelayedSignal();
            await DelayedSignal();
            await DelayedSignal();

            if (_event.WaitOne(0))
            {
                page.ChangeColor(Windows.UI.Colors.Red);
            }
            else
            {
                page.ChangeColor(Windows.UI.Colors.Blue);
            }
        }

        System.Threading.ManualResetEvent _event = new System.Threading.ManualResetEvent(false);
        private async System.Threading.Tasks.Task<bool> DelayedSignal()
        {
            return await System.Threading.Tasks.Task.Run<bool>(() => {
                new System.Threading.ManualResetEvent(false).WaitOne(20 * 1000);
                _event.Set();

                return true;
            });
        }

MainPage.xaml:

    <Grid x:Name="foo" Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">

    </Grid>

MainPage.xaml.cs:

        public void ChangeColor(Windows.UI.Color color)
        {
            foo.Background = new SolidColorBrush(color);
        }

When I deployed this to IotCore and ran it (via F5 and from the Device Portal), the background turned red after ~60 seconds as expected (and the app did not timeout).

I ported this code over to the Sample project (replacing the actual async server invocation and making the MainPage changes to ServerPage). When I deployed that to IotCore, I saw the same behavior ... the app didn't timeout and the background updated to red after a minute.

Do you see the same thing? Or with this simplified code, do you still see the app disappearing?

from ua-.netstandard.

Hi,
i ported your code to the Sampe project, too. I saw your behavior .. the app didn't timeout and the background updated to red after a minute. Now, i am trying out what code from the Sample must be integrated to force a timeout.

from ua-.netstandard.

Hi,
after some hours of debugging and studding the documentation i found in the Window.Activate method documentation.

Remarks (https://msdn.microsoft.com/en-us/library/windows/apps/windows.ui.xaml.window.activate.aspx)
If you use the default app templates from Microsoft Visual Studio, Window.Activate is part of the initial code in the app.xaml code-behind file. Specifically, Activate is called from the default OnLaunched override. In cases where the template produces a page navigation experience, previous states
are detected so that the navigation framework isn't overwritten if it already existed, but Activate is called regardless. Calling Activate is required for all app activation scenario, not just app launch. This method is important for the correct operation of an app. If an app does not call Activate on the Current window, and the app is not visible on screen, then the app will be terminated after 15 seconds.

In my opinion, the GUI thread is not timely initiated after the call to Window.Activate. Therfore the OnLaunched thread will be canceld. With a little trick, suspending the OnLaunched for a short time, the dispatcher can activate the UI Thread an finish the activation and clear the timeout. The OnLaunched now has any time to initialize the opc - ua server stack.

My modification in the async OnLaunched method:
.....
// Ensure the current window is active
Window.Current.Activate();

        // force a dispatcher call
        await System.Threading.Tasks.Task.Run(async () => { await System.Threading.Tasks.Task.Delay(1); });

        try
        {
            // load the application configuration.
            await application.LoadApplicationConfiguration(false);
        .....

I think, the better solution is to move the opc.ua stack initialisation into a splash screen.

from ua-.netstandard.

Thank you both for your totough debugging on this. I have just commited your fix (slightly simplified). Please pull & check if the issue is now resolved.

from ua-.netstandard.

Thank you, i pull the fix and check it. On my PI 3 the issue is resolved.

from ua-.netstandard.

Great!

from ua-.netstandard.