This does not appear to be the same as issue 649348. That issue is a halt at the Chrome OS kiosk app startup screen (CTRL+ALT+S still displaying). With this issue, the fullscreen TestNav splash is showing which indicates the kiosk app has launched and is running.

The attached log files don't seem to be Chrome OS logs. Can you pull the Chrome OS logs by reproducing the issue (and noting the time of repro) then exiting the app or restarting and logging in as a real user and guest then going to:

chrome://net-internals#chromeos

then click "Store debug logs" and upload the file saved. Please also attach the video reproduction. If these files are >10mb, save them to Google Drive or another file sharing app and place the link in your comment here.

Attempted to reproduce the issue on a Samsung Series 3 Chromebook (XE303, Daisy) and was not able. TestNav app launched list of states page.

Are there additional steps necessary to repro?

logs from chrome://net-internals#chromeos
TestNav launched, and was stuck on the "TestNav" screen at 11:03.

Google Drive Links to Videos:
Video showing Chromebook with issue
https://drive.google.com/open?id=0BxpzVu8CM4KrNkV0WmFTWFB0WXM
Video showing Chromebook with issue next to a device working as expected
https://drive.google.com/open?id=0BxpzVu8CM4KreDRxeVp4XzNOb2c

Deleted: debug-logs_20170605-110459.tgz 1.8 MB

debug-logs_20170605-110459.tgz 1.8 MB Download

Shared with Max Kirsch

any updates on this yet?

Is there any additional information we can provide to help shed some light on this situation?

We have not been able to identify what causes the Chromebooks to get caught in this loop of the Kiosk Application failing to fully launch, but when this happens on a device, it will happen after every power cycle of that device. Powerwashing the device seems to correct the issue, but we don't know for a fact that the behavior will not repeat in the future.

We have a single device that this is suffering from this problem, but we have had multiple reports of this happening across multiple makes of Chromebooks (Samsung, Asus, HP, Dell). We will refrain from Powerwashing this device, as we have not been able to reproduce this behavior to the point where we can force scenarios that will cause a device to get stuck in this loop.

We are still working on our end to attempt to determine a root cause, but have been unsuccessful so far.

Any additional assistance would be greatly appreciated.

atwilson@, do you know who could help debug this? Think it has any relation to crbug.com/678829?

I think I may have fixed this issue in our environment.  Within the Google Admin Console:
Device Management - Chrome - Device Settings - User Data
Set to "Do not erase all local user data"

Not sure why this works as the kiosk app is launched prior to any user sign in.  I assume that when this setting is set to delete, the app must download every time the device starts up, which would explain why the hang times have been unpredictable and vary depending on the wireless network the device is attached to.

it sounds like the problem is "first time kiosk launch/initialization is flaky" (since ephemeral mode is forcing app download/config every time).

I don't know what's causing *that* flakiness, but I've refreshed crbug.com/362593 to make kiosk apps ignore ephemeral mode policy.

Ivan/Maksim - note logs in comment #3 - do you see anything suspicious in there explaining why the app might have not loaded?

I haven't found anything helpful in the logs.
However, when I tried to run the given app in the Kiosk mode with chrome Debug, the app's NaCl module is crashing leading the app to freeze exactly at the "TestNav" screen:

[0817/151446.103410:FATAL:ref_counted.h(95)] Check failed: CalledOnValidSequence(). 
** abort() called
** Signal 4 from untrusted code: pc=40f50ffba1e0
[9201:9235:0817/171446.107819:ERROR:nacl_process_host.cc(256)] NaCl process exited with status 64512 (0xfc00)
[9201:9201:0817/171446.126757:INFO:CONSOLE(0)] "NativeClient: NaCl module crashed", source: chrome-extension://mdmkkicfmmkgmpkmkdikhlbggogpicma/window.html (0)

Not saying that it's necessarily related - it could be the Debug build that is just broken.

But it may be that the DCHECK being false highlights some underlying problem in the Native Client, which leads to some incorrect behavior in the Release mode under some circumstances.
The DCHECK that is hit is about threading assumptions violation, which could explain why the issue is hard to reproduce.

This is no longer an issue. This defect can be closed.