#497 Crash at start (after 3 month OK) : how to search

[Trebly]

Hi,
I have installed 1.4.4, 3 months ago, and don't got any problem.
I uses Win10Pro 1803
This morning it doesn't starts (just display the logo and diasappears.

I am not sure but this seeams linked to an access refused to a file linked (not the *.tsk).

TaskManager has required an access to a protected file (probably a link) which has been refused because of the access status changed.
Just after I have allowed the access.

I have not seen anything wrong (first view) into the *.tsk file

How can I debug this and make taskcoach run again normally.

Best regards

Trebly

[Aaron Wolf]

You can clear (or rename) the .ini file https://answers.launchpad.net/taskcoach/+faq/1061 to get TC to a clean state so it won't try to open the same .tsk file. If it runs but then crashes when the .tsk file is opened, it's related to the specific .tsk file. You could possibly manually edit the reference to the changed file within the .tsk file in a text editor. But once we're clear what is happening, it seems a bug to be fixed in TC. That said, we won't likely get to it soon, so the priority is getting your instance functioning again.

[Trebly]

Hi,

Thanks for the quick answer.
What I have done and current problem :
1.- Found ini file but empty 19741 hex\00
2. - rename to force re-init
3. Start succesfully TaskManager
4. Could not open the *.tsk file, because of a false error ? : see joined screencopy
5. Check validity of xml content (utf8) (uses phpstorm)
6. Try to restore from backup : they generate the same error

The question is : What can be the origin of this error ? Because it seems not to be a corrupted tsk file : the backups seems valid xml.

Just found after editing in hex. the tsk and backups
The files get when saved on windows a leading x/0D0A which crashes the parser when file is read.
(I have checked to cut the x/0D0A and TaskManager could load the tsk file successfully)

This is true for the current file and for backups.
Then the remaining questions are :

• Why it was functionning before ?
• Do this x/0D0A was present at the end of the current tsk file or not ?
• Why the ini file could be cleared. May be a local incident ? (I have a backup just one month old, may be I could restore it, for this I don't know at all. I am sure that I have not changed parameters since one month).

This can be a "writeln" which adds in some circumstances the leading x/0D0A when saving the tsk (xml) file not compatible with the parser ?

Best regards

Trebly

---

I join the screencopy of the error while reading the tsk file.

[Aaron Wolf]

You sound more knowledgeable than I (particular on Windows), but my guess about the .ini files is that Task Coach crashed and thus failed to write the .ini correctly. It saves the .ini upon closing. So, if Task Coach doesn't close correctly, the .ini file won't get saved correctly.

Am I understanding that you have gotten the program to work normally at least (make a new task file, it saves, things close as normal etc.)? But you don't have your task file working yet?

[Trebly]

Hi,

Sorry I was wrong.

Truely after cutting the x/0D0A it functions, but not for this reason even it could have been, I explain.
I had renamed the file for test, then because the xml file was right it functions.

In fact the problem is that I had a severe system crash (not explained external cause). Then a file *.delta remains (even empty with 0 byte length or null bytes), and this is the cause of the crash of taskcoach .

I have verified the current valid file and renamed the *.delta and the file has been opened normally.

With the backup the cause was that I had renamed the current and restore the ancient with same name. Then because of the delta file the crash was raised.

The solution seems to be :
1- to rename or delete the delta when it is corrupted or may simply exist after a system crash or not well claused at restart. This can happen when a restart is performed by installer if the soft as tackcoach doesn't locks the system restart or when a severe (instanateneous crash : "computer stopped" quick message.
2- to perform an xml validation of *.tsk file

This should need to look (development ?) at such a complementary "recuparation" process which has functioned (I got back all last data filled : I uses the option "write file tsk" at each change).

Nevertheless there is second problem these of the ini file :
This is the problem that you mentioned.
I had, for test, changed the color of a font. Then I should get a ini file not empty, I was thinking so. I was wrong : to get it TaskCoach must be closed.
The generated ini file before crash has a size changed but filled of null chars.
I have performed a test, before reading your answer, and found that the ini file is written with valid content (text) only when you "quit" taskmanager.
Because I never "quit" TaskCoach since I installed it, like a system task, and let most of softs auto close or lock the close of win session if the application cannot perform his own close automatically.

It seems (I am not sure) that the windows version of task coach doesn't performs this lock and has not auto-close process when system asks for restart. Consequently it is closed always with the risk of loosing data. Not for *.tsk because of the option (write at each change) but for the ini file which has never been written (I worked with default options till today).

So there is a true problem : currently because a windows system can restart after an installation and because sometimes a deep sleep is transformed to a restart, with the current functionment the user has to quit the soft if he wants that parameters changed to be memorized.
May be the problem is that the auto-close has not been performed with a severe and instantaneous crash.
Nevertheless for now if I want to be sure that modified parameters are taken in account I must close and reopen, because the alone way to save the parameters is to close the soft and this is quite never done.

What remains without explanation is that after your first answer, when I looked at the ini file I found a file filled od 19741 bytes of null value !

So, currently I can make function the program and I got back all the data, and there were two problems.

Thanks and best regards,

Trebly

[Aaron Wolf]

Thanks for being so thorough in debugging. Although there's room to improve the program, the two main issues for support documentation are:

• in addition to the .ini, clearing the .delta files may be the solution
• make sure to manually quit Task Coach after setting up preferences / layout and such in order to save those settings