Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I have just installed keepass v2.23 and keep getting the below error, even with the default empty database. File->New, enter name of database, enter master password, repeat password, OK, OK (at step 2), File->Close. File->Open Recent, chose the database just created, enter password and get the following:
Failed to loaded the specified file! '.', hexadecimal value 0x00, is an invalid character. Line 15, position 25.
Running Windows 7. I have tried on another Win 7 box and don't have any issues so I assume it is something to do with a conflict with the .Net framework installation.
A bit of an update on this one. If I create the database file on the Win 7 box where KeePass works and then open that database on the Win 7 box that gave the "Failed to loaded" error, all seems to be fine. I can add entries, delete entries, open and close the database without error.
I believe when the database is first created that a character coding (unicode or whatever) setting or assumption is made by KeePass which if incorrect (for some reason) will cause the error.
It may be an issue with the .NET installation - KeePass uses .NET for almost everything.
Try re-installing .NET.
I have tried reinstalling the .net components that I can without reinstalling the entire OS (including running a couple of .net fix type programs) without success. I have noticed that:
1. Create db, close, read, update, close, read etc all work on the good PC
2. Open same db as in #1 on the bad pc, close, read all work
3. Save a change to the db on the bad pc and the db no longer opens on the bad or good pc
So it must be something in the write process on the bad pc causing the problem.
Could I upload the db somewhere for someone to take a look?
You could turn off file transactions - just a thought.
Tools > Options > Advanced. File Input /Output.
Please post the file here (click 'Add Attachment' right of the 'Post' and 'Cancel' buttons).
Thanks and best regards,
Thanks Dominik. I have created a new database and immediately saved it without entering any settings apart setting the password to be: password
If I now try to open that db I get the "Failed to load the specified file - hexadecimal value 0x00" error.
Thanks. I was able to reproduce the issue and have isolated it.
Attached is the unencrypted inner XML data of the database. The nodes MasterKeyChangeRec and MasterKeyChangeForce should contain the value '-1', however they actually contain '-�ͳ1', so between the '-' and the '1', garbage was inserted. In hex the garbage is 26 23 78 30 3B CD B3; the CD B3 sequence in UTF-8 forms the Unicode character U+0373 (Greek Small Letter Archaic Sampi) and the XML parser translates the first part to a 00 byte, so the garbage actually is a null byte plus a Greek letter.
Unfortunately, I have no idea how this could be caused. I reviewed the serialization code, but it looks ok.
Anyone else has an idea?
If sd73 could take a look at the locale settings on the PC that's writing that file, that would give a clue. Go to Control Panel, Region and Language, Formats tab, Additional settings button, Numbers tab, and have a look at the Negative sign symbol. If it isn't just a "-" then it could be the problem. Or I think the Greek locale might have some other weirdness with number formatting too... either way, if the "Negative" example doesn't start with a plain "-123" then it's going to be a problem.
Dominik, I think the issue with the serialization code is that if you have to serialize numbers as strings, you should do it in the invariant locale, not the system locale. Check out KdbxFile.Write.cs WriteObject() methods. .ToString() uses Thread.CurrentCulture, which is not the invariant locale. I'd recommend either using XmlConvert.ToString and the equivalent parsing methods (seeing as it's XML your serializing to), or if you can't use the XmlConvert for some reason, at least pass CultureInfo.InvariantCulture as the parameter to ToString for everything that's being serialised rather than UI-displayed.
Good idea, Alex, thanks! That might indeed explain the garbage (although I wonder why/how a null byte can be used in a number format).
I've now added NumberFormatInfo.InvariantInfo as parameter to the ToString calls (this is what XmlConvert does internally; I don't want to use XmlConvert, because its efficient 'Try*' methods are internal only) and changed the reading methods accordingly.
Here's the latest development snapshot for testing (sd73, databases created with this build should work fine on your 'bad' PC):
Yeah, it's a bit weird. As far as the Win32 API calls for getting locale info go, the returned string ought to be null-terminated, so completely impossible to get a null character in there. It's possible there's a bug with the CLR locale implementation and it's a buffer overrun of sorts, I suppose. On the other hand, your Unicode idea is another possibility, U+0373 is suspiciously close to U+0374: "Greek Numeral Sign". Could be a coincidence, of course.
In any case, might be an idea for backwards compatibility to have KeePass fall back on parsing using the old CurrentCulture method if the new Invariant one fails, otherwise there's always a chance that someone using a weird locale won't be able to open their database any more.
Things are looking good. KeePass_130915.zip works. Also looking in Control Panel, Region and Language, Formats tab, Additional settings button, Numbers tab I have for Negative "-Gp123,456,789.00". No idea why there is the "Gp" in the format string. All my other Region and Language settings are set to (I believe) standard UK settings.
I clicked the Reset button on the Numbers Tab and the "Gp" disappeared.
Glad to hear it works now; thanks for testing!
I've added the fallback to the current culture, if the invariant one cannot parse the number.
Thanks for getting it to work with my weird config.