▲ 0 r/Office365+1 crossposts

Case Study: Excel 365's Removal of Practical Local AutoSave Creates Unnecessary Operational Risk

Case Study: Excel 365's Removal of Practical Local AutoSave Creates Unnecessary Operational Risk

Executive Summary

I recently lost several hours of accounting work while using Microsoft Excel 365 on a Mac.

The file was stored on my local SSD.

There was no crash, no power failure, no operating system fault, and no hardware issue.

The work was lost because Microsoft Excel 365 does not provide true AutoSave to locally stored files, despite the fact that periodic saving to local storage has been a standard desktop software capability for decades.

This is not primarily a technology issue.

It is a product-design decision.

Background

I am a Microsoft 365 subscriber with access to 1 TB of OneDrive storage.

I deliberately do not use OneDrive for certain workflows because I work offline for significant periods of time and prefer local storage for operational reasons.

The issue is therefore not a lack of cloud storage.

The issue is that Microsoft appears to have tied modern AutoSave functionality to cloud-based workflows while failing to provide an equivalent mechanism for users who store files locally.

The Incident

I was preparing accounting journals for upload into an accounting system.

Several hours were spent editing and validating data.

When I attempted to upload the journals, validation errors were reported.

I reopened the Excel file to investigate and discovered that a substantial portion of the work performed during the session had not been saved.

No crash occurred.

No warning was issued.

No usable recovery file was available.

Several hours of work had to be recreated.

The Fundamental Problem

The problem is not OneDrive.

The problem is not cloud storage.

The problem is not version history.

The problem is that Excel 365 does not provide a straightforward mechanism to automatically save changes to a file that already exists on a local SSD.

A local SSD is:

  • fast
  • reliable
  • writable
  • always available when the computer is running

There is no obvious technical reason why Excel could not save changes to a local file every 30 seconds, every minute, or every five minutes.

Desktop software has been performing this function for decades.

Historical Context

Prior generations of desktop software routinely provided periodic saving and recovery mechanisms for locally stored files as a normal part of application design.

Saving data automatically to:

  • a local hard drive
  • a file server
  • a network share

has never been a technically difficult problem.

The concept predates cloud computing by many years.

Microsoft's current approach therefore appears to be a deliberate product decision rather than a technical necessity.

Risk and Compliance Implications

This issue should concern:

  • accountants
  • auditors
  • risk managers
  • compliance professionals
  • governance professionals
  • legal practitioners
  • users operating in offline environments

Many organisations intentionally maintain local-first workflows due to:

  • confidentiality requirements
  • regulatory considerations
  • operational resilience requirements
  • unreliable connectivity
  • cybersecurity policies

The ability to protect users from losing work should not depend on cloud adoption.

Questions for Discussion

  1. Why does Excel 365 not provide true AutoSave to local SSD storage?
  2. Why should protection against data loss require a cloud-based workflow?
  3. Is tying AutoSave functionality to cloud services an acceptable design decision for professional users who work offline?
  4. Should risk and compliance teams reassess the operational risks associated with cloud-dependent productivity software?

Conclusion

The issue is not whether OneDrive is useful.

The issue is whether a professional desktop application should be capable of automatically saving changes to a file stored on the same computer on which it is running.

That capability existed in practice long before cloud computing became commonplace.

The inability of Excel 365 to provide true local AutoSave represents an unnecessary operational risk and, in my case, resulted in the loss of several hours of accounting work.

reddit.com
u/ET-Cartman — 5 days ago
▲ 11 r/PanasonicToughbook+1 crossposts

Panasonic Toughbook CF-33 Mk1 — intermittent hard POST failure after hibernate-resume crash, DIY diagnosis exhausted

Picked up a second-hand CF-33 Mk1 (i7-7600U, 16GB DDR3 soldered, 512GB SATA SSD), did a clean Win10Pro Panasonic Recover install than forced a Win11 Pro update install, ran great for weeks as a headless RDP box.

The trigger: Closed the lid to hibernate one evening. Never woke up. Forced shutdown, and from then on: solid green power LED, no POST, no Panasonic logo, no beep (occasionally a single non-chime beep). EC clearly alive the whole time — battery charging/LEDs, backlight hotkeys, and power-button short/long-press all behaved correctly — but the CPU/chipset handoff to POST just wasn't happening.

What I ruled out, methodically:

  • Full capacitor drain (battery+AC out), tested from 30 min up to 3 days — no effect
  • Docking station — tested tablet-only, no change
  • Internal display — tested external HDMI monitor, no video either way
  • RAM — soldered, not a variable
  • CMOS/RTC battery — disconnected 15 min, no lasting fix
  • Battery presence — fails identically on AC-only

It did eventually recover, after about a week of failed attempts — intermittently, unpredictably, with no controllable variable (drain duration, AC vs battery) correlating to success. It reached a "Bad System CMOS" prompt once, pressed F2, and got frozen cursor and unresponsive keyboard. One time only. Not repeatable. Continued with only the green power light coming on. Then one day, the full Panasonic logo appeared before hanging. One time only. Not repeatable. Continued with only the green power light coming on. Then finally, after taken the batteries out for at least 2 whole days, tried to power up, Panasonic logo appeared, then displayed ">>Checking media presence and >> No media present" and eventually booted into Windows. That window of working access was what let me pull Event Viewer logs.

Confirmed root cause of the original trigger, via those logs: Kernel-Boot Event ID 16: "Windows failed to resume from hibernate with error status 0xC0000411" — the documented STATUS_HIBERNATION_FAILURE code — immediately followed by an unclean-reboot Critical event (Kernel-Power 41) and an "unexpected shutdown" (EventLog 6008). A Panasonic firmware update had also been silently pushed via Windows Update a month earlier (28/6) — can't confirm it caused this, but it's a plausible contributing factor given the timing.

The twist: Disabled hibernate entirely (powercfg /hibernate off) and set Sleep to Never (plugged in) for RDP reliability. System ran fine for over a week. Then it died again — this time triggered by me choosing Restart instead of Shutdown, no hibernate involved at all**.** Same dead symptoms as the original failure.

Where I've landed: EC is functioning correctly across every test; the fault sits between EC and CPU/chipset POST completion. It's recurred on two different trigger types (hibernate-resume, and separately a plain restart) and hasn't correlated to any variable I can control. This is DIY-exhausted — next step is a repair shop with rugged-laptop board-level experience (voltage rail monitoring / thermal imaging), since a sealed tablet with soldered RAM isn't realistic for me to board-swap myself.

Posting in case anyone's seen this exact failure signature on a CF-33, or has thoughts on what's worth asking a repair tech to check first.

Photos

  1. Stuck at Bad System CMOS. Once F2 is pressed, see (2)
  2. Cursor appeared and stuck. trackpad couldn't move it. Left it like that for a day before switching off.
  3. Got to the Panasonic Logo and stuck. Left it like that for a day before switching off.
  4. video: finally booted after over 1 week. Worked for about 1 week and the "can't get past POST" situation came back.
u/ET-Cartman — 2 months ago