broken json file

[georgi-iovchev]

Hi, Something very strange happened to me. A json file got corrupted. The last thing I did to this file was editing a comment for it through CX. Then later (after a reboot for something else) when I need to see more details in CX about the particular test, the file was not shown in CX. I manually located it and it's not valid json. Somehow it got some binary data in it, very strange:

[DevTechProfile]

Never happened on my systems. Do you have unstable memory OC or a broken SSD?

[georgi-iovchev]

I have some cpu (curve optimizer) and mem oc (3600->3733), but I am sure it's stable (heavily tested, and in use for the last 1.5 year). The ssd that keep the records - I am not sure about it. I utilized it recently, it's a samsung oem nvme left after I upgraded my daughters laptop, and according to hwinfo it's on 99% life.

It's a bit complicated scenario. I have two windows installation - one daily on my main nvme, and one clean on this secondary nvme. I do the recordings from the secondary windows (and the recording are also stored there). And later on I may analyze the results from my daily windows. So I find the CX log from where I analyzed the json from my daily windows and it looks perfectly fine:

{"@t":"2023-11-15T15:19:52.3010166Z","@mt":"File changed: {path}","path":"E:\\CX_Caputres\\details\\CapFrameX-AC2-Win64-Shipping.exe-2023-11-15T24748.json","SourceContext":"CapFrameX.Data.RecordDirectoryObserver"}
{"@t":"2023-11-15T15:19:52.3040270Z","@mt":"{filePath} successfully written","filePath":"E:\\CX_Caputres\\details\\CapFrameX-AC2-Win64-Shipping.exe-2023-11-15T24748.json","SourceContext":"CapFrameX.Data.RecordManager"}
{"@t":"2023-11-15T15:19:52.3040270Z","@mt":"File changed: {path}","path":"E:\\CX_Caputres\\details\\CapFrameX-AC2-Win64-Shipping.exe-2023-11-15T24748.json","SourceContext":"CapFrameX.Data.RecordDirectoryObserver"}
{"@t":"2023-11-15T15:19:52.5013983Z","@mt":"Loading data from: {path}","path":"E:\\CX_Caputres\\details\\CapFrameX-AC2-Win64-Shipping.exe-2023-11-15T24748.json","SourceContext":"CapFrameX.Data.RecordManager"}
{"@t":"2023-11-15T15:19:52.5167070Z","@mt":"Loading data from: {path}","path":"E:\\CX_Caputres\\details\\CapFrameX-AC2-Win64-Shipping.exe-2023-11-15T24748.json","SourceContext":"CapFrameX.Data.RecordManager"}

And a bit lower the quit:

{"@t":"2023-11-15T15:29:08.0701181Z","@mt":"Error while closing ADL/ADLX","@l":"Error","@x":"System.DllNotFoundException: Unable to load DLL 'atiadlxy.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)\r\n   at PInvokeDelegateFactoryInternalWrapperType22.ADL_Main_Control_Destroy()\r\n   at OpenHardwareMonitor.Hardware.ATI.ATIGroup.Close()"}
{"@t":"2023-11-15T15:29:08.3052692Z","@mt":"WebServer (http://*:1337) State - Stopped"}

So far looks ok, it's not CX to blame, after all it quit fine. I looked also in windows event viewer for disk errors or something similar and there is 0 problems. So it's a mystery. Anyway, in the broken json file in the binary gibberish data there are some readable strings. They don't talk anything to me, but may be you can get a clue:

This program cannot be run in DOS
d:\hotproject\winring0\source\dll\sys\lib\amd64\WinRing0.pdb
IofCompleteRequest
IoCreateSymbolicLink
IoCreateDevice
IoDeleteSymbolicLink
RtlInitUnicodeString
IoDeleteDevice
MmUnmapIoSpace
MmMapIoSpace
KeBugCheckEx
ntoskrnl.exe
HalSetBusDataByOffset
HalGetBusDataByOffset
HAL.dll
C_specific_handler
hiyohiyo@crystalmark.info
http://crl.globalsign.net/Root.crl0
GlobalSign nv-sa1
Root CA1
GlobalSign Root CA0
GlobalSign RootSign Partners CA1
RootSign Partners CA1
Primary Object Publishing CA100
GlobalSign Primary Object Publishing CA0
GlobalSign Time Stamping Authority1
timestampinfo@globalsign.com
http://crl.globalsign.net/RootSignPartners.crl0
http://crl.microsoft.com/pki/crl/products/MicrosoftCodeVerifRoot.crl0
https://www.bing.com/WS/Init","Pivot"

On my side I dont insist for analyzing, the issue can be closed. It was just interesting what happened, but I guess it will stay mystery.

[DevTechProfile]

Thanks for the info. I would rather classify this as a "singular event".