Autorecovery not working. Where is recovery information saved?

[Ivan - Tracker Software]

Also, if you have any fresh PDFXEdit.exe.XXX.dmp files in your "c:\Users\[username]\AppData\Local\CrashDumps" folder, please zip them and send to us please.

[David.P]

Hello Daniel and Ivan,

Sorry for not getting back earlier.

Since PDF-XChange Editor literally never crashes on its own, this issue only comes up again when external factors cause a system crash.

This time, Windows completely crashed. However, as has been the case most of the time, after rebooting and restarting PDF-XChange Editor, no recovery information was found or presented.

This occurs despite the fact that PDF-XChange Editor clearly does save auto-recovery information as configured in the settings:

PDF-XChange Editor Autorecovery Settings.png

Autorecovery option settings and Document Recovery dialog (immediately after crash and reboot)

PDF-XChange Autorecovery Folder Content.png

PDF-XChange Editor saving autorecovery information while running, but last saved state before the crash is three days old

For this crash, no crash dumps were generated in the designated crash dump folder, so I am unable to provide any logs this time.

Why does PDF-XChange Editor seem to be saving auto-recovery data but fail to retrieve any after a crash?

Best regards,
David

[Daniel - PDF-XChange]

Hello, David.P

without the logs Ivan requested, there is little I can gleam from this information, however, there is one known bug in 395 which could have an impact here. At the moment the, Recovery panel will not be displayed until you have opened any one document (eg, open editor, and use Ctrl+N to open a new blank file, recovery panel should appear).

If you have not already proceeded beyond this point, can you try opening a blank document, and see if that shows the recovery data there?

I should also note that this particular "delayed-recovery-display" bug is already slated for a fix in the next (396) release.

Kind regards,

[David.P]

Hello all,

unfortunately I have to report that Autorecovery continues to not work for me.

This time, PDF-XChange Editor crashed for no apparent external reason. It didn't actually completely crash, but became unresponsive when flipping through PDF pages, and I had to terminate it via Task Manager.

I made a screenshot of the Autorecovery directory while PDF-XChange Editor was hanging, and another screenshot after it was terminated.

image(2).png

Screenshot of Autorecovery directory before the crash: last Autosave was about 15 minutes before the crash (and not 3 minutes as should have been according to the Autosave option settings)

image(1).png

Screenshot of Autorecovery directory immediately after the crash. Note that all Autorecovery data until about 1.5 hours before the crash was deleted during the crash for mysterious reasons.

Unfortunately, there was nothing to be found in the crash dump directory.

image.png

Contents of the Document Recovery panel after the crash and restart of PDF-XChange Editor: nothing at all of the current document, last Autorecovery data saved about 10 hours before the crash.

image(3).png

Autosave option settings

Please advise.

Best regards
David.P

[Daniel - PDF-XChange]

Hello, David.P

Thank you for the further report, I have informed Ivan of this once again, and am awaiting his directions.

Did you by any chance capture a "process dump" from the Editor, before force closing it? https://www.pdf-xchange.com/knowledgeba ... estigation

If not, Please keep it in mind next time, as it could contain some relevant data for us.

Kind regards,

[Vasyl - PDF-XChange]

Hi David.

There may be one known, simple, but annoying bug: the Document Recovery pane does not load existing recovery data until you open any document. Can you confirm whether you are experiencing this issue or another one?

This bug will be fixed in the upcoming build, by the way...

Cheers.

[Daniel - PDF-XChange]

Hello, once again,

In the meantime, we have heard back from Ivan.
To begin, Not everything present in that folder is autorecovery data, the tmp folder holds a number of other items as well, so the disappearing act is expected.

• In this case, there is only one file present here which is autorecovery information, and that file was not one of the ones deleted. This seems to imply there was only one document open which had changes made to it, though that is unclear from your description. Could you please confirm if you had more than one document open, where changes had been made more than 3 minutes prior to the hang?
• In any case, Vasyl's question above is pertinent. Did you open any document OTHER than the one which needs recovery, after the issue occured, to see if the recovery pane would appear and present that document?

Following that, I should also clarify that "force closing" the app through the task manager is not a crash, and will not be treated as such by windows. In turn, such a process will never generate crash dumps, unless the act of attempting a force close lead to some other error unrelated to the hang that is occuring.

One final question from Ivan, the files which you had opened at the time of this hang. Were they newly opened from a standard location, or were they perhaps items which were restored from the previous session? Either:

• 1. by opening directly from the recovery panel, or
• 2. by enabling the "restore last session when application starts" option in the preferences?
• (If yes to either, please specify which).

Kind regards,

[David.P]

Hello all,

thanks for the replies and for taking care of this issue.

I just had another crash. This time, the laptop completely crashed, probably due to some hardware issue or overheating.

After rebooting, the document recovery panel was empty, although I had set Autorecovery to save every 3 minutes, as I always do.

Below are my answers to the recent open questions.

Did you by any chance capture a "process dump" from the Editor, before force closing it?

This was not applicable this time because a hardware issue caused the crash.

There may be one known, simple, but annoying bug: the Document Recovery pane does not load existing recovery data until you open any document. Can you confirm whether you are experiencing this issue or another one?

Did you open any document OTHER than the one which needs recovery, after the issue occured, to see if the recovery pane would appear and present that document?

I have yet to test this variant.

Could you please confirm if you had more than one document open, where changes had been made more than 3 minutes prior to the hang?

I believe I only had one document open or at least was working only on one document at that time.

One final question from Ivan, the files which you had opened at the time of this hang. Were they newly opened from a standard location, or were they perhaps items which were restored from the previous session?

The files were newly opened from a standard location in all cases.

[Daniel - PDF-XChange]

Hello, David.P

Thank you for letting us know, I have passed this information along to the Dev team, One key item of note though is this point:

Did you open any document OTHER than the one which needs recovery, after the issue occured, to see if the recovery pane would appear and present that document?

I have yet to test this variant.

This is very likely to be the issue you have experienced this time, and it is fixed for V10.6. If you can reproduce a crash in 10.6, please do let us know if the recovery pane appears as expected on restart for you.

Kind regards,

[David.P]

I will definitely do so. Thank you, Daniel, for following up on this issue.

[Daniel - PDF-XChange]

Hello, David.P

in the meantime, I am doing my best to find as many crashes as possible before 10.6 is released, so we can prevent the issue before it happens!

With that said, based on your previous reports, you may want to look into taking some corrective action for your Device.. It sounds like it is itself a bit of a problem causer, with all these random overheats and other such issues you are encountering.
I cannot help but wonder if there is something related to all those issues, leading to your particularly unique set of issues with our autorecovery function.

Kind regards,

[David.P]

Thank you, Daniel!

However, please note that the issue has been occurring with many different devices over the years, e.g. with massive desktop workstations, with small laptops from different manufacturers, and also with my latest Lenovo P16 Gen 2 animal.

Best regards,
David

[Stefan - PDF-XChange]

Hello David.P,

Thanks for the feedbackl It is well noted, and I will make sure Daniel and the devs keep looking into this!

Kind regards,
Stefan

[David.P]

Did you open any document OTHER than the one which needs recovery, after the issue occured, to see if the recovery pane would appear and present that document?

I have yet to test this variant.

This is very likely to be the issue you have experienced this time, and it is fixed for V10.6. If you can reproduce a crash in 10.6, please do let us know if the recovery pane appears as expected on restart for you.

Today I had another computer crash due to a driver update issue. I believe I opened another document after rebooting. However, I'm not absolutely sure because it could be that the document that was open during the crash was automatically opened again.

Anyway, in the document recovery panel, there were only two documents that were about a week old.

This was on version 10.6.0 build 395. I have since updated to build 396.

[Daniel - PDF-XChange]

Hello, David.P

Thank you for keeping us posted. While I still think you really need to investigate and resolve the issue of your system crashing so frequently... I have spoken with the Dev team once again. This may feel like going in circles, but, please see below:

Next time that you have a crash of any sort, please zip the Editors Tmp folder before you launch our software, just as before.

1. Next time that a crash occurs, before you relaunch the editor, navigate to our temp folder:
%tmp%\PDFXedit
2. Backup this entire folder (copy it to your desktop or something easily accessible) ensure you leave the original files within it in place.
3. Re-open the editor to see if the error occured.
4 A. If it did, please zip the backed up temp folder, and email it to us for investigation.
4 B. if the error did not occur, and the autorecover is working as intended, that is great, you can delete the backup, and just kindly let us know all is well.

Then, if there is only old recovery data in place, please send that data to us. Below I have a link to a placeholder fileshare folder for this issue, the current link will only last 1 week, but if this issue does not come back in a week, please post here and I will refresh it so you can upload the zip archive you have recorded. As long as you have placed the tmp folder in a zip file, and moved that elsewhere before opening the software, it is okay to continue using the software as normal.

You can upload the files here: https://files.pdf-xchange.com/s/t8FDZNiLtyWZncm
As before, if the link does not work, let me know and I will revive it for you.

Kind regards,

[David.P]

Thank you, Daniel.

Please note that the various system crashes are caused by different issues and can occur on completely different systems. There's currently a lot of changes happening both within the company and in my personal setup due to massive IT system changes, and reinstalls.

Therefore, it is clear that the issue is not a problem with one of the many different systems that I'm using and where this issue has been occurring for years, regardless of whether or not PC crashes are involved.

For example, the issue has been happening for years on various "locked" company systems where PDF-XChange Editor was installed as a portable version, as well as on various personal laptops where it is always fully installed.

Thank you for keeping up with this issue. I will keep everyone posted.

Best regards
David

[Daniel - PDF-XChange]