The customer at 17197509 reports that after he changed the proxy settings, the device is no longer crashing. I'll proceed with asking for more details but for now, JSON with policies can be found at https://drive.google.com/file/d/1X_GA5BaDRd7ZE22PdjKC6Irn-sch_ZYo/view?usp=sharing

poromov, please assign for reproduction/bugfixing

Looks like it might be related to network stack as changing proxy settings resolved it and also there were these errors in the stack:

2018-10-17T09:30:58.403725-05:00 ERR shill[1023]: RTNETLINK answers: No such file or directory
2018-10-17T09:30:58.403862-05:00 ERR shill[1023]: Command failed -:1
2018-10-17T09:30:58.404026-05:00 ERR shill[1023]: RTNETLINK answers: No such file or directory
2018-10-17T09:30:58.404109-05:00 ERR shill[1023]: Command failed -:2
2018-10-17T09:30:58.404685-05:00 ERR shill[1016]: [ERROR:error.cc(138)] [throttler.cc(313)]: disabling throttle failed: 1
2018-10-17T09:30:58.404722-05:00 ERR shill[1016]: [ERROR:error.cc(138)] [throttler.cc(120)]: 

Could it be similar to https://crbug.com/706962 ?
Kirtika, could you have a look?

Routing to Drew to take a look at it first.

#c5 : the throttle warnings are benign and unrelated. 
bandwidth throttling is not being used here and also has nothing to do with proxy settings. 

Raising priority due to crash. ppaz: Can we find out what policies were set that make it crash? The post-crash policies aren't that useful, and I can't see details of the troublesome proxy settings from the screenshots.

++ case 17372255

Same Stable Signature00000f7e-exit2-ui, so I attached this signature to this bug.
69.0.3497.120 coral

2018-10-31T14:34:22.806323-04:00 WARNING crash_reporter[14505]: [user] Received crash notification for chrome[14253] sig 4, user 1000 (ignoring call by kernel - chrome crash; waiting for chrome to call us directly)
2018-10-31T14:34:22.916642-04:00 INFO session_manager[13663]: [INFO:session_manager_service.cc(297)] Browser process 14253 exited with signal 4 (Illegal instruction)
2018-10-31T14:34:22.917030-04:00 INFO session_manager[13663]: [INFO:browser_job.cc(157)] Terminating process group for browser 14253 with signal 9: Ensuring browser processes are gone.


More logs and crashes:
https://drive.google.com/open?id=1PeqOvEJD2ew1V1y3fZkroG-jJcD6dHAk

Server crash ID:
810001ebda16273e
5dc00dc31ab59d2b

Cannot collect policy, because it immediately crashes upon login and goes back to sign-in screen.

I had a quick look at the logs and couldn't find anything obvious. Any policies to repro this on our side would be very helpful.

@ppaz + marchuk + vkhabarov:
1) Any info about policy settings would be helpful here (e.g. bad policy with M68). 
2) Do the other crashes also get resolved with different proxy settings?

Initial reporter case was closed, as it was fixed for the customer. What they did to fix was changing User Settings> Network >Proxy Settings in Admin Console from "Always auto detect" to "Allow user to configure". So -
1. Always auto detect causes crashes for them (reliably)
2. Allow user to configure - no crashes.

I wasn't able to reproduce this on a reks device with M69 or M72 with either proxy settings.

It confirms that there is a crash somewhere in network stack when proxy auto detect is configured. However, it looks like it's reproduced not in 100% cases, but when there is some special proxy configuration in the network (which Chrome OS is trying to auto-detect).

Victor, could you please ask the customer to share their real proxy configuration in the network?

We just saw ~400 panther VC devices inside google with a possibly similar issue: 

crash/4a407f0cc8ef7928
crash/bd52f531ecde6222
https://listnr.corp.google.com/report/85832510435

crash/ autolinked to this bug, but it's hard for me to tell if it's the same issue.  If anyone has insight into whether the linked crashes are the same as this, or how to go about investigating, it would be very helpful.

Hello Team,

Do we have any update for this bug? 

Thanks!

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.