New User Crash (Have Fix Solution)

[wuyilingwei]

Crash immediately after opening about 3-5s and exit instead of being unresponsive. Use 3.2.0 with .net 6, I had try 3.1.1 and it also crash. I reinstall .net6 from microsoft but not any use. All security software has been disabled and administrator rights have also been tried. This is the event record of Windows: (xml)

[-] <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
[-] <System>
  <Provider Name="Application Error" Guid="{a0e9b465-b939-57d7-b27d-95d8e925ff57}" /> 
  <EventID>1000</EventID> 
  <Version>0</Version> 
  <Level>2</Level> 
  <Task>100</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8000000000000000</Keywords> 
  <TimeCreated SystemTime="2024-03-07T05:08:37.6700511Z" /> 
  <EventRecordID>108263</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="23408" ThreadID="10232" /> 
  <Channel>Application</Channel> 
  </System>
[-] <EventData>
  <Data Name="AppName">CompactGUI.exe</Data> 
  <Data Name="AppVersion">3.0.0.0</Data> 
  <Data Name="AppTimeStamp">65ab2b45</Data> 
  <Data Name="ModuleName">KERNELBASE.dll</Data> 
  <Data Name="ModuleVersion">10.0.22621.3155</Data> 
  <Data Name="ModuleTimeStamp">8c2ee5db</Data> 
  <Data Name="ExceptionCode">e0434352</Data> 
  <Data Name="FaultingOffset">0000000000065b0c</Data> 
  <Data Name="ProcessId">0x2cc</Data> 
  <Data Name="ProcessCreationTime">0x1da704d819f8e39</Data> 
  <Data Name="AppPath">D:\CompactGUI.exe</Data> 
  <Data Name="ModulePath">C:\Windows\System32\KERNELBASE.dll</Data> 
  <Data Name="IntegratorReportId">42c24c81-e7e1-40f2-ada5-52a5a80358be</Data> 
  <Data Name="PackageFullName" /> 
  <Data Name="PackageRelativeAppId" /> 
  </EventData>
  </Event>

Version Windows 11 Pro Version 23H2 Installation date 2022/11/10 Operating system version 22631.3155 Experience the Windows Feature Experience Pack 1000.22684.1000.0

If you need more detailed information please tell me.

[wuyilingwei]

I checked some recent issues and I noticed %LOCALAPPDATA%\IridiumIO\CompactGUI had been created. I find one problem: settings.json is empty!!!!!!(it shows 0kb so I looked it) This does not comply with the json specification so I add [] in it and it looks work. That may the problem why it not working. I guess your application created a settings.json without writing anything, and then crashed directly when reading it because it did not comply with the json specification.

[wuyilingwei]

Solution: If new install try run this command in cmd.exe

echo [] > %LOCALAPPDATA%\IridiumIO\CompactGUI\settings.json

It can fix error settings.json file.

[ForbiddenEra]

I also can confirm this issue. Never used this app before, both the standalone and integrated versions crashed shortly after opening.

Good call on OP for quickly realizing an empty JSON file wouldn't be valid.

The fix provided works, though the app complains the settings file is corrupt and that it'll be restoring the defaults.

Not entirely unexpected, but odd that there's a corruption check that doesn't catch the parsers' exception?

Though, as a JS developer, I still think it's odd that an empty array is considered a valid JSON object. I mean, of course technically in JS an Array is just an Object anyway..?

Oddly enough, if your settings.json contains only an empty object {} instead of an empty Array [], it still crashes shortly after launch, but with an empty Array, it pops up with the corruption dialog.

Out of curiosity, I also tried an array containing an empty object ([{}]) and that doesn't crash but results in the corruption popup as well. This made me think that perhaps the app is expecting the parsed result to be returned as an Array instead of an Object (forgive me for not being fully up to speed with .net and details regarding JSON parsing with .net) thus the settings file actually consisting of an Array of objects and/or other values, but I just looked and settings.json after being re-written with the defaults and at the outermost, it's indeed an object, which sorta makes me wonder why ` and{}crashes but[]and[{}]` doesn't..?

I can only think that when empty (`), the parser throws an exception that's not handled and[]throws an exception that is handled as corruption (perhaps that the returned object is an Array type and not an Object type?) but{}wouldn't cause the parser to throw an exception, the resultant object would be of the Object type, passing that check but then crashing when something subsequent attempts to access a non-existent property? Likewise, if indeed[]triggers an exception because of it being an Array type,[{}]` would trigger the same exception.

I'm only speculating and again not particularly familiar with .net specifically and only to satisfy my own innate curiosity. ;-)

That said, perhaps the corruption check should also verify that the whatever minimum required properties exist in the returned object before accessing any of them.

But of course, the initial/core issue is that the file itself wasn't created properly upon first startup, the crash is a side-effect of that issue, though if the error handling around this was slightly more complete than at worst the core issue should've caused the corruption pop-up and not the crash; I struggled to word this properly as I didn't want to say "handled better" as clearly the developer had at least some forethought in error handling here, hence the pop-up recognizing the 'corruption' and re-creating the file with defaults anyway which I don't want to take away from as I see a ton of laziness or just not caring when it comes to error handling scenarios these days so I always want to recognize effort in that direction - no one can consider every possibility in advance and it's not fair to have that expectation when you have the hindsight of knowing an issue that wasn't considered!

Anyhow; technically there's two, possibly (likely?) three issues here:

• settings.json not being created correctly when it doesn't already exist (eg. for new users, though deleting the file alone is enough to cause the crash)
• The exception thrown during parsing not being handled (thus causing a crash) when the above case is true
• Possibility of a third exception thrown when there's only an empty object {} inside settings.json; admittedly this could be the same exception as above as it's crash manifests the same, however, JSON parsers generally throw a fit when passed an empty string but won't complain about an empty object {}, thus my educated guess/assumption is that likely subsequent access to an expected-but-missing property is causing it's own unexpected-and-not-caught-exception right after parsing.

Anyhow, thanks @yige-yigeren for providing a workaround in the meantime. I've not used this software before but figured I'd give it a chance since I can't be bothered to deal with the CLI for this (or mostly anything on Windows, damn I hate PowerShell and even traditional cmd.exe/command.com shells compared to anything Unix-like - I'll take the most bare sh over PowerShell anyday!)

[Iridium-IO]

@ForbiddenEra funnily enough there is a check in the program to rebuild the file if it is empty -.-

It's been there for ages but my new attempts to fix the corrupted files have made things worse. It's really dumb, but the issue was simply that the program attempts to create the settings file twice in separate threads, resulting in a crash. I moved the creation check to the application startup (rather than waiting for the window itself to show), but forgot to actually remove it from the window code.

This is now (hopefully for the last time) fixed in v3.2.1

[wuyilingwei]

I also can confirm this issue. Never used this app before, both the standalone and integrated versions crashed shortly after opening.

Good call on OP for quickly realizing an empty JSON file wouldn't be valid.

The fix provided works, though the app complains the settings file is corrupt and that it'll be restoring the defaults.

Not entirely unexpected, but odd that there's a corruption check that doesn't catch the parsers' exception?

Though, as a JS developer, I still think it's odd that an empty array is considered a valid JSON object. I mean, of course technically in JS an Array is just an Object anyway..?

Oddly enough, if your settings.json contains only an empty object {} instead of an empty Array [], it still crashes shortly after launch, but with an empty Array, it pops up with the corruption dialog.

Out of curiosity, I also tried an array containing an empty object ([{}]) and that doesn't crash but results in the corruption popup as well. This made me think that perhaps the app is expecting the parsed result to be returned as an Array instead of an Object (forgive me for not being fully up to speed with .net and details regarding JSON parsing with .net) thus the settings file actually consisting of an Array of objects and/or other values, but I just looked and settings.json after being re-written with the defaults and at the outermost, it's indeed an object, which sorta makes me wonder why ` and{}crashes but[]and[{}]` doesn't..?

I can only think that when empty (`), the parser throws an exception that's not handled and[]throws an exception that is handled as corruption (perhaps that the returned object is an Array type and not an Object type?) but{}wouldn't cause the parser to throw an exception, the resultant object would be of the Object type, passing that check but then crashing when something subsequent attempts to access a non-existent property? Likewise, if indeed[]triggers an exception because of it being an Array type,[{}]` would trigger the same exception.

I'm only speculating and again not particularly familiar with .net specifically and only to satisfy my own innate curiosity. ;-)

That said, perhaps the corruption check should also verify that the whatever minimum required properties exist in the returned object before accessing any of them.

But of course, the initial/core issue is that the file itself wasn't created properly upon first startup, the crash is a side-effect of that issue, though if the error handling around this was slightly more complete than at worst the core issue should've caused the corruption pop-up and not the crash; I struggled to word this properly as I didn't want to say "handled better" as clearly the developer had at least some forethought in error handling here, hence the pop-up recognizing the 'corruption' and re-creating the file with defaults anyway which I don't want to take away from as I see a ton of laziness or just not caring when it comes to error handling scenarios these days so I always want to recognize effort in that direction - no one can consider every possibility in advance and it's not fair to have that expectation when you have the hindsight of knowing an issue that wasn't considered!

Anyhow; technically there's two, possibly (likely?) three issues here:

• settings.json not being created correctly when it doesn't already exist (eg. for new users, though deleting the file alone is enough to cause the crash)
• The exception thrown during parsing not being handled (thus causing a crash) when the above case is true
• Possibility of a third exception thrown when there's only an empty object {} inside settings.json; admittedly this could be the same exception as above as it's crash manifests the same, however, JSON parsers generally throw a fit when passed an empty string but won't complain about an empty object {}, thus my educated guess/assumption is that likely subsequent access to an expected-but-missing property is causing it's own unexpected-and-not-caught-exception right after parsing.

Anyhow, thanks @yige-yigeren for providing a workaround in the meantime. I've not used this software before but figured I'd give it a chance since I can't be bothered to deal with the CLI for this (or mostly anything on Windows, damn I hate PowerShell and even traditional cmd.exe/command.com shells compared to anything Unix-like - I'll take the most bare sh over PowerShell anyday!)

I found that version has the function of automatically repairing the configuration. To be honest, if I write all config into the command line and want to complete the repair, I must write a .bat file. So I just fixed the json format error.

[wuyilingwei]

I used to know this error, and the exception because of empty json was often very. . . abstract. So when I see a 0kb json file, I used to go to see what’s going on : (

[wuyilingwei]

@ForbiddenEra funnily enough there is a check in the program to rebuild the file if it is empty -.-

It's been there for ages but my new attempts to fix the corrupted files have made things worse. It's really dumb, but the issue was simply that the program attempts to create the settings file twice in separate threads, resulting in a crash. I moved the creation check to the application startup (rather than waiting for the window itself to show), but forgot to actually remove it from the window code.

This is now (hopefully for the last time) fixed in v3.2.1

Thanks for the fix, I didn't read the source code in detail so I can only give the cause of the error and a temporary solution. @.@

[ForbiddenEra]

in separate threads

I've been coding since the mid '90s, threads will always get ya ;)

I do a lot of server side JS these days though, almost no one uses threads. I do; but for most, 'threads' is just adding more 'replicas' to your kubernetes deployment manifest (if you're not familiar, it's basically spinning up extra completely separate containers [light weight VMs] running your process completely separately) which is insane, but hey, I also see stuff with 900+ libraries added with 80-90% of them doing things you could do yourself in a few lines of code but instead of learning you copy/paste from the internet.

Anyhow, g'job on the quick fix. Cheers.