As Kenneth said, I made a demo app testing the portions of code that mimic user interaction but without interaction, I was able to take a screenshot as expected. Here's the unlisted app that tested this:
https://chrome.google.com/webstore/detail/test/lmobegalmmkkabnopakjhlnahklkkoig

When user-input is detected, screen-capture will fail. Please see here - https://support.google.com/chrome/a/answer/6179663?hl=en

Please ask them if it is consistently failing across all devices and ask them to upload logs after screen-capture failure with machine S/N and domain name. 

There is no user input however. These Chrome devices don't even have HID devices attached.

To try to get to the bottom of this, we inspected the code for API calls which we suspected might be treated as user input (even though they're not user input). You can see these calls in the above-mentioned Google Cloud Connect thread.

This issue occurs 100% consistently across all of our devices to which our Chrome app is deployed.

Which logs would be useful? I'd prefer to upload the bare minimum to a public forum like this.

Please send your system logs to Mike and I can get it from him. As discussed in the thread, things like Bluetooth attached peripherals, Camera etc. can prevent the screen capture.

jennyz@ can you please take a look and assign accordingly.

Here are the attachments

Hi Ivan, would we be able to identify the exact reason for error code 1 from device logs?

We see the following in the logs:

2017-04-24T21:26:07.682501+01:00 ERR chrome[598]: [598:598:0424/212607.667917:WARNING:status_uploader.cc(144)] User input ET_MOUSE_MOVED detected 1.06605e+06 s ago (14.785 s after last boot), data upload is not allowed.
2017-04-24T21:26:29.471682+01:00 ERR chrome[598]: [598:598:0424/212629.471600:WARNING:status_uploader.cc(144)] User input ET_MOUSE_MOVED detected 1.06607e+06 s ago (14.785 s after last boot), data upload is not allowed.

Understood that these devices have no HID devices attached, and yet the system is reporting mouse input (touch screen? Some hiccup in the hardware drivers?). Is the kiosk app auto-launched or are you launching it from the login screen manually? If it's auto-launched and there's absolutely no input devices connected to these boxes, then the next step is for QA to try to repro this internally and input team can investigate where the phantom user input is coming from.

Great that we've narrowed this down at last!

There are no HIDs attached. There are also no touchscreens attached. The only thing that is attached is a USB hub, but this was also attached when we tried taking screenshots with Chrome Sign Builder running on the devices - and that works fine.

The Kiosk app is auto-launched. The devices are in single app kiosk mode and everything is configured through Chrome device management.

If you look at the Google Cloud Connect thread mentioned in the original post on this thread (https://connect.googleforwork.com/thread/18421), there are some snippets of code there from our app that we wondered whether might be responsible for generating phantom user input.

I don't think so. I could suggest removing the call to requestPointerLock() in your app and see if the problem happens, but it seems unlikely to me.

Raj, sending over to you - the next step is to find someone on Puneet's team who can look into why mouse events are being generated if there are no peripherals attached. From the kiosk point of view, screenshot blocking is working correctly so not much to do on the remote command side.

Actually, I believe Mike already tested our app with those calls removed and screenshot-taking still didn't work.

adlr@, can you please help triage this?

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Wednesday, 12/12/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

Due to lack of action this bug has been Archived. If work is still being done on this issue or you are still experiencing this issue please feel free to re-open with the appropriate information.