Crash on startup #123

Closed
odgeza opened this Issue Jul 14, 2015 · 11 comments

Projects

None yet

2 participants

@odgeza
odgeza commented Jul 14, 2015

Version: 1.0.25.82; Variant: Installed; Arch: Amd64
Path: C:\Program Files\SyncTrayzor\SyncTrayzor.exe
System.Xml.XmlException: '.', hexadecimal value 0x00, is an invalid character. Line 1, position 1.
at System.Xml.XmlTextReaderImpl.Throw(String res, String[] args)
at System.Xml.XmlTextReaderImpl.ParseRootLevelWhitespace()
at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
at System.Xml.Linq.XDocument.Load(XmlReader reader, LoadOptions options)
at System.Xml.Linq.XDocument.Load(Stream stream, LoadOptions options)
at SyncTrayzor.Services.Config.ConfigurationProvider.LoadFromDisk(Configuration defaultConfiguration) in c:\projects\synctrayzor\src\SyncTrayzor\Services\Config\ConfigurationProvider.cs:line 142
at SyncTrayzor.Services.Config.ConfigurationProvider.Initialize(Configuration defaultConfiguration) in c:\projects\synctrayzor\src\SyncTrayzor\Services\Config\ConfigurationProvider.cs:line 87
at SyncTrayzor.Bootstrapper.Configure() in c:\projects\synctrayzor\src\SyncTrayzor\Bootstrapper.cs:line 88
at Stylet.BootstrapperBase.Start(String[] args)
at System.Windows.Application.<.ctor>b__1(Object unused)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)

@canton7
Owner
canton7 commented Jul 14, 2015

Hmm, looks a lot like #120, but the poster there disappeared before I could get any useful information out of him!

So: did you do anything before starting SyncTrayzor (the first time that it crashed like this)? Did you upgrade it? Shutdown your computer? Anything else that probably isn't relevant, but would be good to mention just in case?

Could you pastebin C:\Users\<You>\AppData\Roaming\SyncTrayzor\config.xml somewhere (or paste it in here)? I'm interested in whether the whole file's been corrupted, or just the first few bytes, or whether there's nothing else, or....

Once you've saved your corrupted config.xml somewhere, you can rename/delete C:\Users\<You>\AppData\Roaming\SyncTrayzor\config.xml and start SyncTrayzor again, which should re-generate it. You'll lose data such as what notifications are enabled (the things in File -> Settings), but your Synthing configuration (devices, folders, etc) will be fine.

Thanks!

@odgeza
odgeza commented Jul 14, 2015

My PC ran out of power today.

The contents of it is a whole bunch of "NUL" if open it notepad++
Any other app show its as blank (notepad.exe or IE etc).

Renaming the file works as you suggeted (I did eventually find the other language version of the error in #120

@canton7
Owner
canton7 commented Jul 15, 2015

Roughly how many NULs? Are we in the region of 10s, 100s, 1000s, etc?

@odgeza
odgeza commented Jul 15, 2015

there are 1927 NULs

@canton7
Owner
canton7 commented Jul 15, 2015

Thanks! OK, so it's basically the right length but everything's NULL. Sounds like we opened it and were just about to write to it (so the filesystem helpfully zeroed everything out to avoid security issues) when everything rebooted. We only write to that file pretty rarely (after initial start-up), so you must have got very unlucky!

I'm looking into making this write more robust...

@odgeza
odgeza commented Jul 15, 2015

Perhaps having a fallback/rollback file would be more reliable?

@canton7
Owner
canton7 commented Jul 15, 2015

That's actually surprisingly hard to get right. Using TxF looks like a better option.

@odgeza
odgeza commented Jul 15, 2015

Hi,

I just mean something like, copy the file to rollback version, and try write changes to current version. Once current version checked as "re-readable" again. Delete rollback version. If it fails mid-write, you would be able to rollback to the copied version, and rewrite it to the main version again, and then delete it.

Assuming here, that when you re-read the file that was just written, its not somehow still showing you cache from what you wrote, but is actually going to re-read the fully written file.

@canton7
Owner
canton7 commented Jul 15, 2015

It gets more complex than that, and it's an area I don't particularly want to get into. Especially given that Windows has support for atomic file writes anyway, which I might as well just tap in to.

@canton7
Owner
canton7 commented Jul 15, 2015

Actually, MoveFileEx looks like the recommended approach nowadays

@canton7 canton7 added a commit that referenced this issue Jul 15, 2015
@canton7 Use an atomic(ish) write to the config file
Should help #123
d771daa
@canton7
Owner
canton7 commented Jul 16, 2015

This should be fixed in v1.0.27. Let me know if you still see issues.

@canton7 canton7 closed this Jul 16, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment