Specific Periodic Crashes (every 9.5 mins) on Windows 10

Prerequisites

• Put an X between the brackets on this line if you have done all of the following:
  • Reproduced the problem in Safe Mode: https://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
  • Followed all applicable steps in the debugging guide: https://flight-manual.atom.io/hacking-atom/sections/debugging/
  • Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
  • Checked that your issue isn’t already filed: https://github.com/issues?utf8=✓&q=is%%3Aissue+user%%3Aatom
  • Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description

Periodic crashes (every ~9.5 minutes) on Windows 10. This is similar to 2 previously reported issues but it is not because of a proxy or VPN and this is not on Mac OS X. Also, Atom does not feel ‘sluggish’ as described in the Mac OS X issue. It performs perfectly normally up until the exact moment it crashes. No crash report log is given to me upon reopening Atom.

I have followed the flight manual:

• Latest version of Atom (1.28.0)
• Tried in safe mode -> no change
• Cleared saved state
• Reset to factory defaults
• Checked for linked packages (despite the fact I haven’t done development on Atom itself)
• Haven’t changed any config files

Steps to Reproduce

1. Start Atom
2. Wait 9.5 mins
3. Crash

Expected behavior: [What you expect to happen]
It not to crash

Actual behavior: [What actually happens]
It crashes

Reproduces how often: [What percentage of the time does it reproduce?]
9.5 minutes after launch

Versions

C:\Users\jlc_c>atom --version

Atom    : 1.28.0
Electron: 2.0.3
Chrome  : 61.0.3163.100
Node    : 8.9.3

C:\Users\jlc_c>apm --version
apm  1.19.0
npm  3.10.10
node 6.9.5 x64
atom 1.28.0
python
git 2.13.2.windows.1
visual studio

Running Windows 10 Pro (version 1803) on a Surface Pro 4 – i5 8GB RAM, 256GB SSD

Additional Information

Can add crash dump files if needed.
Also tried changing the File System Watcher to the ‘Experimental Filesystem Watching Library’ to see if it was something to do with the default watcher as this seems like it is periodic in nature; did not work.

— Edit —
Forgot to mention, this problem still persists on the 1.29 beta