Crash during Upload on OfflineStorageSQLite

[jpalmaduran]

Describe your environment.
Reproduced on Windows 11, Solutions/version.txt is 3.6.999.1

Steps to reproduce.
This is a race condition that is a bit tricky to reproduce and as consequence not easy.

• Create an object that holds an instance of the logmanager (Do not use the singleton/global instance) and during the destructor calls UploadNow()
• Create a shared pointer instance of a that class
• Create a thread that gets an instance of that ptr (we should have the atomic counter value to two).
• Ensure that thread outlives Main.

We need to reproduce the following.

• Main finishes. (Our object should have atomic counter to 1)
• Singletons clean up process starts, destroying any 1ds internal shaningans
• Thread finishes and sets the object count to 0 calling its destructor.
• Destructor calls logmanager->Uploadnow()
• Crashes

What is the expected behavior?
Internal constructs of 1ds should be bound to lifecycle of the loggers not the process. The process should control the lifecycle of the logger.

What is the actual behavior?
Process crashes at shutdown

Additional context.

[jpalmaduran]

Adding up to where I can add in the stack trace:

Microsoft::Applications::Events::OfflineStorage_SQLite::GetRecordCountUnsafe		0x000000000000006A				OfflineStorage_SQLite.cpp		897
Microsoft::Applications::Events::OfflineStorage_SQLite::GetRecordCount		0x000000000000005E				OfflineStorage_SQLite.cpp		920
Microsoft::Applications::Events::OfflineStorageHandler::GetRecordCount		0x0000000000000053				OfflineStorageHandler.cpp		149
Microsoft::Applications::Events::TelemetrySystem::upload		0x0000000000000023				TelemetrySystem.cpp		205
Microsoft::Applications::Events::LogManagerImpl::UploadNow		0x0000000000000048				LogManagerImpl.cpp		440

[bmehta001]

Hi jpalmaduran, This is likely mitigated by #1520: the factory and PAL singletons now remain valid throughout process teardown, avoiding a destruction-order use-after-free when a log manager is used late; SQLite storage also receives explicit/destructor shutdown cleanup. This matches the reported late UploadNow() scenario, but we have not reproduced the exact thread-outliving-main crash. Closing as likely addressed; please reopen with a current stack trace if it persists.