Autorecovery not working. Where is recovery information saved?

David.P · Post by **David.P** » Mon May 27, 2019 10:05 am

Hi forum and Tracker Support Team,

after a crash of PDF-XChange Editor, unfortunately no Autorecovery of the crashed document is offered -- although Autorecovery is activated, with a 5 minutes saving interval.

Also, strangely, only one window crashed and not the entire Editor, i.e. another open Editor window continued to run perfectly. In addition, Editor does not offer me any recovery information at all for today, although I have already worked with various PDF documents for several hours today.

Can I manually look for any recovery information under a specific file path?

Thanks for any ideas
Regards
David

Mon May 27, 2019 2:19 pm

Hello David,

The usual path is %temp%\PDFXEdit

...but you can also access the recovery copies if you enable this option:

I hope this helps.

Regards.

David.P · Post by **David.P** » Fri May 31, 2019 6:34 pm

Many thanks Dimitar, for the helpful information.

Interestingly, there are numerous folders like for example "pdfx-{09571710-1DA5-41F0-84C83510570BBCA8}" under this path, each however only containing 256 kB of data (in the form of two small XML and TMP files).

The actual PDF document from the autorecovery session, which, as the case may be, could be much larger, therefore seems to be saved somewhere else?

Best regards
David

Fri May 31, 2019 7:55 pm

Hello David,

The original PDF is stored its usual location, the autorecovery backup simply holds onto the list of changes that have been made to the document (the same items that appear in the Undo/Redo flyout menu), this is backed up periodically, and if the editor closes unexpectedly, this information is not purged like usual. The next time it opens, the Editor sees the remnant files and says "oh hey, something happened, better ask if they still want these!".

If it was possible to completely save the document in cases like crashes (and other situations where auto-recover kicks in) than having this kind of auto-recovery function would not be necessary to begin with.

Kind regards,

David.P · Post by **David.P** » Mon Nov 25, 2019 4:02 pm

Hi forum & Tracker Support Team,

Unfortunately, today PDF-XChange editor crashed once more, and took about 1 hour of work down with it.

Despite AutoRecovery being activated,

...the Recovery Panel does not offer any saved documents of today.

In the AutoRecovery path %temp%\PDFXEdit, I found the following files:

Please let me know what might have gone wrong here, and whether I can recover any of the changes made in the last hour from these temp files.

Best regards
David

Mon Nov 25, 2019 4:48 pm

Hi David.
Did you have Editor crash or PC crash/reboot?
Also, from file list you provided there is one strange thing: in folder pdfx-{D3....} there is file PDFXRecoveryInfo.xml (it contain recovery metadata like path to original file and changed objects timestamp), but does not contain file PdfStr5.tmp (it contain updated data and is required to recover PDF file).
Recovery panel offer recovery only when both PDFXRecoveryInfo.xml and PdfStr5.tmp are present and original PDF file was not modified since PDFXRecoveryInfo.xml was created/updated. In your case one file is missing, thus no recovery is offered. Do you use some cleaner or any other app that may delete PdfStr5.tmp?

David.P · Post by **David.P** » Mon Nov 25, 2019 5:10 pm

Hi Victor,

I had PDF-XChange Editor crash -- and I don't use any auto-cleaner software.

This is what a flat view of the %temp%\PDFXEdit folder looks like in the meantime (after continuing to work with PDF-XChange Editor):

Now, there is no files of today anymore.

Do you have an idea what I could do to could repair/reactivate AutoRecovery for the future?

Thank you
David

Mon Nov 25, 2019 6:20 pm

Hi David.

David.P wrote: ↑Mon Nov 25, 2019 5:10 pm I had PDF-XChange Editor crash -- and I don't use any auto-cleaner software.

But file was gone, and I don't know why. Looks like we need to test AutoRecovery on your PC. It is very easy to do this:
1. Enable it with minimal interval.
2. Open one local file and modify it (for example add an annotation on first page).
3. Leave Editor for more that AutoRecovery interval to be sure that recovery record will be created.
4. Kill Editor process (for example using Task Manager).
5. Optional - check Editor temp folder.
6. Run Editor again. Recovery panel should display one file to recover. It may not popup automatically because of your settings, so please open it manually if needed using View -> Panes -> Document Recovery.
If this does not work - we will need remote session to check what is going on.

David.P wrote: ↑Mon Nov 25, 2019 5:10 pm This is what a flat view of the %temp%\PDFXEdit folder looks like in the meantime (after continuing to work with PDF-XChange Editor):
image.png

Now, there is no files of today anymore.

Normally Editor clean all temporary folder where no valid recovery information is found at start, so this is expected.
Looks like you have recovery data for several different documents (old ones). Do you really need them? Each additional sub-folder slowdown Editor startup time for a bit (and also there will be more records in recovery panel.

HTH.

David.P · Post by **David.P** » Mon Nov 25, 2019 10:11 pm

Thank you Victor for the analysis.

I will make sure to check the issue this way, and come back with the results.

Cheers
David

Tue Nov 26, 2019 12:13 am

We look forward to those results, Thank you in advance!

David.P · Post by **David.P** » Wed Jan 08, 2020 12:41 pm

Hi Victor & Daniel & forum,

a short interim information on this. Unfortunately, AutoRecovery is still not working (this is on build 336).

While temporary files are created in the temp folder of PDF-XChange Editor (%temp%\PDFXEdit), they disappear (most of them, sometimes all) immediately even if PDF-XChange Editor is killed with Task Manager or Process Explorer.

PXE Temp folder after crash before restarting PXE

PXE Temp folder flat view after crash after restarting PXE

PXE Temp folder flat view after killing PXE after 6 minutes

Accordingly, no recovery is offered after PDF-XChange Editor is started after a crash, and the recovery panel is then empty.

Thanks for any ideas. This is on Windows 10 build 1809.

Best regards
David

Wed Jan 08, 2020 1:03 pm

Hi David.
Do you have some "Cleanup" software which may clean temporary files? Or maybe drive where temp folder is almost full?
You need to investigate why files disappear and fix this, otherwise autorecovery will not work.

David.P · Post by **David.P** » Wed Jan 08, 2020 2:04 pm

Thank you Victor -- I use no software of this kind.

Strangely, the PDF-XChange Editor temporary files disappear within a split second when PDF-XChange Editor is killed via Task Manager.

The temp drive is here and there's around 40GB free space on the C drive:

C:\Users\[username]\AppData\Local\Temp\PDFXEdit

Thu Jan 09, 2020 7:15 am

Hi David.

David.P wrote: ↑Wed Jan 08, 2020 2:04 pm Thank you Victor -- I use no software of this kind.

But some program is deleting required files, so you will need utility to monitor which program is doing this. You may try use this one or any other with needed functionality. Please investigate and write here results.

David.P · Post by **David.P** » Thu Jan 09, 2020 8:35 am

Ok Victor -- will do and report back!

Thank you
David

Tue Jan 14, 2020 1:28 pm

Thanks David,

Looking forward to your feedback!

Regards,
Stefan

David.P · Post by **David.P** » Mon Feb 15, 2021 1:02 pm

Hello forum and Tracker team,

I still don't fully understand how Auto Recovery works.

I just accidentally closed a PDF document, after some editing, without saving it.

In the "Document Recovery" pane, this document shows up as "unsaved document", with the exact time I closed it (13:46):

However, when I open this Document Recovery entry, the document opens in the previous version, and the edits up to 13:46 are not present.

Then I just closed and reopened the Editor once, and now the top entry in the "Document Recovery" pane is no longer there.

Is this expected behavior, or has something gone wrong?

Wed Feb 17, 2021 10:10 pm

Hi, David.P

The document recovery pane should only kick in if the editor closes unexpectedly, without prompting you to save the documents, such as if you leave it open and force close during a system restart. to be more specific, the "recovery files" are created periodically while the document is opened, and should be deleted when the document is closed normally. So if the app crashes, that would be the only situation where the files should still exist.
The "recovery versions" created here should simply be a log of changes that occurred since opening, think of it like opening a document, and clicking the "redo" button enough times to redo everything up to the moment it was last saved.

As such, there are two takeaways here.
1. It is expected that becuase you opened the "recovered" version, looked at it, and closed it normally, that it should be been removed from the recovery pane.
2. It it unexpected, and likely a bug, that you did not see any of the changes which were saved in that file upon opening it. If you can reproduce this reliably, please let us know so I can have our dev team weigh in on it and see what can be done to prevent or resolve it. If you could also provide a detailed step-by-step of what you do, and how you are "closing" the editor so that the recovery files remain in place that would be helpful.

Kind regards,

David.P · Post by **David.P** » Tue May 31, 2022 2:28 pm

Hello Forum and Tracker Team,

unfortunately, the document recovery still does not work reliably for me.

I just had to restart the PC via reset button while some PDF documents were open in PDF-XChange Editor. One of the documents had been continuously edited for at least 1 hour.

Nevertheless, PDF-XChange Editor apparently did not save any recovery information in the %temp%\PDFXEdit folder, although according to the settings it should have done so every 3 minutes:

In the %temp%\PDFXEdit folder, only the following can be found (which seems to match with the contents of the Recovery Panel):

The last time I manually saved the document in question before the crash was at 14:33:

The crash/restart happened around 15:49.

What could still be going wrong there?

Best regards
David

igorlima · Post by **igorlima** » Tue May 31, 2022 5:29 pm

Hi all!

Just want to report in that the autorecovery function also does not work for me when a crash of pdf xchange happens.

For me, the crashs I'm referring to are the ones reported in this topic: https://forum.pdf-xchange.com/viewtopic.php?f=62&t=38752&p=160193#p160193

I understand that these crashes are already being addressed, but I just want to contextualize my autorecovery problem, I already had data loss because of that, and to add my input in this topic.

The only time the autorecovery function works for me is when I close a file without saving it.

Thank you for the support!

Post by **Paul - PDF-XChange** » Tue May 31, 2022 9:29 pm

Thanks for these posts guys.

It seems things are not working as expected. I have asked the devs to look into it, but be aware that we have had to re-assign the dev for this due to staff changes.

I hope to have a discussion tomorrow with the dev who will take over this.

We will definitely look further into this.

David.P · Post by **David.P** » Sat Jul 23, 2022 8:42 am

Hello all,

Unfortunately, the automatic recovery still hasn't worked for me yet. Luckily, there have been no major crashes in the meantime, where a lot of work would have been lost.

Today, however, I face the problem that my laptop had been disconnected from the network for some time and had also been in stand-by during that time. All that time a PDF file was open that I had been working on for a few hours before, and that resides on a network file server.

After waking up the laptop from stand-by I got the following message from PDF-XChange Editor, before the network connection could be restored:

Does this message mean that the "unsaved changes" are immediately recovered as soon as the file is reopened from the original location, even though that location contains an older version of the file?

Anyway, I now left PDF-XChange Editor in this state in order to not do the wrong thing, and to ideally salvage my yesterday's work on that PDF file.

PDF-XChange Editor also created the following recovery information:

(The original file size is 74 MB; and there are also a few more recovery folders from yesterday that may be associated with the file in question, however the above folder is the one with the latest timestamp)

Unfortunately, the recovery information seems to be uber-locked and therefore cannot be copied elsewhere while PDF-XChange Editor is still running.

I worry that if I close PDF-XChange Editor normally, the recovery information might get deleted for some reason.

What should I do now? Kill PDF-XChange Editor via Task Manager, and then try to recover the document, based on the above recovery information?

Thanks for any suggestions!

Best regards
David

Mon Jul 25, 2022 3:37 pm

Hello, David.P

David.P wrote: ↑Sat Jul 23, 2022 8:42 am After waking up the laptop from stand-by I got the following message from PDF-XChange Editor, before the network connection could be restored

This message will try to restore any potentially lost data, but if, on re-opening the file, we detect that the original document was changed elsewhere, the changes will be lost, the same would happen with the auto-recover function in this case. Clicking re-open is what I would recommend here since the result will be the same with both features. Though I should note that without knowing personally that the file is entirely unchanged by any other devices since you started working on it, I cannot promise that it will restore your changes, it is possible that it will only re-open the original document without any of the changes you made.

In the future, Do try to avoid letting the device go to sleep without saving changes, as it can cause complications like this (anything which disables the network adapter, or causes a network connection to drop temporarily can, in fact). Increasing the auto-sleep timer in windows would be recommended to mitigate this issue.

Kind regards,

David.P · Post by **David.P** » Thu Oct 06, 2022 2:54 pm

Hello all,

just dropping by to say that unfortunately, Auto Recovery continues to not work for me.

While PDF-XChange Editor virtually never crashes, it does happen that there are crashes of one of my various PC's.

However, I have never been able to observe that anything useful is found in PDF-XChange Editor's Autorecovery after a crash that could be restored. There are always certain recent documents listed in Autorecovery, however never the ones that were open when the crash actually happened.

Does anyone out there have better experiences with Autorecovery?

Thanks
David

Post by **Paul - PDF-XChange** » Thu Oct 06, 2022 4:19 pm

Hi David,

we are looking into improvements in how this works. I was under the impression we had made changes recently, but I could be wrong.

I assume this report is for the latest version of the Editor, currently 9.4.364.0?

David.P · Post by **David.P** » Thu Oct 06, 2022 5:26 pm

Hello Paul,

I just realized that I'm actually running the previous version 9.4.363.0 here.

In any case, I shall update and continue to monitor/report about the Autorecovery behavior.

Thank you,
David

Thu Oct 06, 2022 5:59 pm

Hello, David.P

Thank you for that. in case the update does not resolve the issue, the Dev team has a few steps they have asked if you can follow.

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.

Kind regards,

David.P · Post by **David.P** » Wed Oct 26, 2022 5:10 pm

Hello Forum and Tracker Team,

Here comes the next report about problems with Document Recovery.

My laptop just crashed while some PDF documents were open in PDF-XChange Editor. One of the documents had been continuously edited for several hours.

Unlike before, PDF-XChange Editor did save recovery information this time:

(Flat View of recovery folder)

I am using the portable version, so the recovery directory is located at
C:\Users\USERNAME\AppData\Local\Temp\PDFXEdit.Portable

The contents of the Recovery folder seemed to match with the Recovery Panel, after rebooting):

The last time I manually saved the document in question before the crash was at 17:59:

The crash/restart happened around 18:34.

However, when I clicked on "Recover", the following error message appeared:

I have noticed that I have not lost many edits, so I do not need the broken recovery session fixed.

So, unfortunately, I still have not been able to experience a functioning document recovery.

However, the error now seems to be less severe than before, where no recovery information was saved at all.

I have sent the zipped recovery folder to your mail address.

Best regards
David
--

PS: These are the Recovery settings and the "About" box:

I shall update to build 364 asap.

Post by **Paul - PDF-XChange** » Wed Oct 26, 2022 6:03 pm

Thanks David, we have the files and are looking into it as soon as a dev is available for this.

regards

David.P · Post by **David.P** » Fri Oct 28, 2022 3:02 pm

Hello all,

PDF-XChange Editor just crashed, immediately restarted itself and opened the previous session, however in the last manually saved state of the documents.

No current recovery was offered. The Recovery Pane only showed documents from yesterday and the day before, and the associated Recovery folder apparently still contains the exact same files as posted above on October 26.

However, I am still on (portable) build 363.

The crash happened when trying to scale the size of some pages. There are some bugs in the Scale Pages dialog that only occur with certain combinations of selected pages and enabled options in the dialog. As soon as I can reproduce the buggy combinations deliberately, I will report in another thread.

Issues seem to occur with certain combinations of the "Orientation", "Normalize", and "Scale Content" options.

I shall keep you posted.
Best regards
David

Post by **Paul - PDF-XChange** » Fri Oct 28, 2022 5:29 pm

Hi David,

we have two aspects to this, we need to determine why the Document Recovery data was not there, and we also need to determine why the crash happened.

Is the crash document related? If so can we have it?

The dev team are aware of the Document Recovery issues but other tasks have taken their time. We are now in a position to prioritize this behaviour, the ticket RT#6283: Auto-recovery issues has been created with a high priority.

David.P · Post by **David.P** » Fri May 05, 2023 4:52 pm

Hello all,

has Document Recovery ever worked for anyone?

For me, it continues to never work.

Fortunately, at least, PDF-XChange Editor almost never crashes by itself

Post by **Paul - PDF-XChange** » Fri May 05, 2023 5:49 pm

Hi, David.P

It always works for us, and our issue is that we cannot reliably reproduce the case. Can we either do a remote and watch you reproduce this or can you put together a numbered list of the steps you take that reliably reproduces the issue?

I feel like we are chasing our tail here and am keen to get some hard data on what is going on for you. What are your feelings about that? Remote or no?

Kind regards,
Paul - Tracker Supp

rakunavi · Post by **rakunavi** » Sat May 06, 2023 6:53 am

Hello David.P,

David.P wrote: ↑Fri May 05, 2023 4:52 pm has Document Recovery ever worked for anyone?

Here, the auto-recovery feature is working fine on multiple machines. However, the crash itself does not occur because the apps are extremely stable in my environment. At best, I have only experienced auto-recovery mode in the case where I reported a bug here (viewtopic.php?t=39769) (resolved in build 367) and in the case where the app crashes when the data transfer method is set to native mode on a specific scanner (plustek OpticBook 3600). Of course, the auto-recovery feature works fine when the process is forced to stop.

As for the scanner, it works fine if the data transfer method is set to memory mode, and the TWAIN driver for plustek OpticBook 3600 has already stopped being updated after the last release for Windows 8, so it is rather a miracle that it works. Other scanners work fine whether the data transfer method is set to native mode or memory mode, so I have determined that this issue is entirely caused by the outdated TWAIN driver and have not specifically reported it here in the forum.

It may not mean much to report that everything works fine, but just FYI.

Best regards,
rakunavi

Mon May 08, 2023 7:42 pm

David.P · Post by **David.P** » Tue May 09, 2023 5:05 pm

Hello all,

thanks to the Tracker Support for offering remote support. Since the feature seems to work fine for others, I'm assuming that I have some kind of configuration issue on my end.

The problem occurred the other day on my laptop. However, there I am running the 64bit version of PDF-XChange Editor as portable installation (using a little hack). Maybe this is the reason I'm having issues.

I shall keep monitoring if Recovery works, in particular on my regular installation on the main PC, and report back in due time.

Best regards
David

Post by **Paul - PDF-XChange** » Tue May 09, 2023 5:22 pm

Hi, David.P

if you can do that it would be great.

We need the temp files again. When a crash happens:

send the crash dump
before starting the Editor again go to %temp% and zip up the subfolder "PDFXEdit"
send us both the crash dump and the PDFXEdit temp files archive. https://www.pdf-xchange.com/knowle ... le-service

Kind regards,
Paul - Tracker Supp

David.P · Post by **David.P** » Tue May 09, 2023 5:27 pm

O.k. will do Paul!

Post by **Paul - PDF-XChange** » Tue May 09, 2023 7:45 pm

David.P · Post by **David.P** » Mon Nov 06, 2023 12:19 pm

Just a quick note to say that the recovery feature has been working flawlessly for me lately

Thanks for the hard work and for the continuous improvements!

Best regards
David

Mon Nov 06, 2023 2:05 pm

Hello David.P,

Happy to hear that, and many thanks for the kind words!

Kind regards,
Stefan

David.P · Post by **David.P** » Fri Aug 09, 2024 8:52 am

Hello all,

Unfortunately I'm currently seeing problems with Autorecovery again.

PDF-XChange Editor Plus Portable build 387 just crashed around 10:30 after about one hour of work.
I'm having it saving recovery information every 3 minutes via the option settings.

There even seems to be some current recovery information saved in the path
C:\Users\[username]\AppData\Local\Temp\PDFXEdit.Portable:

Note that LastBootUpTime after the crash according to Windows PowerShell was 10:32:02.

Also, I am not offered to recover any of today's recovery information when looking at the recovery panel in PDF-XChange Editor.

Is there a way to manually force PDF-XChange Editor to open any of today's recovery information?

Or is there not even any usable recovery information available of today, before the crash?
If yes, why would that be so, given that autosave is set to a three-minute interval?

This is a brand new Windows 11 workstation.

Please advise.

Fri Aug 09, 2024 10:53 am

Hello David.P,

I will ask our devs to take a look and advise on this issue you are experiencing!

Kind regards,
Stefan

David.P · Post by **David.P** » Fri Nov 08, 2024 9:28 am

Just as an intermediate update on this, I continue to see that Autorecovery doesn't work as intended, unfortunately.

I have set it to auto-save every three minutes, but I almost never see that anything has actually been saved when checking the Document Recovery window after a crash

This doesn't mean that it doesn't save anything, since if I go into the Document Recovery window, I see that occasionally things have been auto-saved.

However, I don't remember Autorecovery ever having served its actual purpose: finding and being able to recover a document that has been auto-saved before a crash.

Tue Nov 12, 2024 7:27 pm

Hello, David.P

I am just going back a little bit trying to refresh myself on this topic,

1. I note that earlier on you mentioned the crash can be a single application window, while the others stay open? This should not trigger a recovery action, as the application as a whole is still running, however, I am more concerned as to why only one window would close to begin with... Is that still happening, or are these full application crashes now?

2. Auto-recover will only appear and offer information if the original files have not been changed since they were last opened. If these files are located on a shared resource, there is a chance anyone else is working on them as well. Should they have saved any changes to the document, autorecover will see that as a "changed" file and the old recovery information cannot be used and will not be presented (This is a file stability issue, trying to apply changes to an altered document could corrupt the file, so that data is deemed unusable).

3. You mentioned that you are using an x64 portable with "a little hack" (one I expect I am familiar with), we do now offer an official x64 portable version, perhaps exporting your application settings via the UI, downloading the new Portable (x64) (choose from list) and then importing those settings into a new/clean portable folder, could help to rectify the issue. I wonder if part of the problem is perhaps leftover files in your portable directory from "updating" of the portable files via manual overwriting.

If the issue continue even when using the official x64 portable version without any manual file manipulation, please do follow the steps Paul mentioned before, and send us a copy of the temp folder, as well as the crash dump that was generated before you relaunch the application.

Paul - Tracker Supp wrote: ↑Tue May 09, 2023 5:22 pm When a crash happens:

send the crash dump

before starting the Editor again go to %temp% and zip up the subfolder "PDFXEdit"

send us both the crash dump and the PDFXEdit temp files archive.

Kind regards,
Paul - Tracker Supp

Please let us know if it happens again, and if after zipping the crash and tmp files are collectively over 20MB (too large for most email clients). In that case, we will create an upload link for you.

Kind regards,

David.P · Post by **David.P** » Tue Dec 03, 2024 6:10 pm

Thanks all for the continued work on PDF-XChange Editor and for the great service.

I just had a crash with PDF-XChange Editor, possibly due to a conflict with Listary when trying to save something from PDF-XChange Editor.

This time, auto-recovery seems to have fully worked

Just for completeness, I have been using the normal portable version of PDF-XChange Editor for a long time.

About the crash dump, I believe I couldn't do that in this case because I don't have admin rights on this machine.

I tried to import the registry key that makes the machine create a crash dump, but it wouldn't let me import it into the registry.

Best regards
David.P
--
Below is the content of the temp folder of PDF-XChange Editor at the time of the crash:

After restarting PDF-XChange Editor, the folder looks like this:

Tue Dec 03, 2024 11:35 pm

Hello, David.P

If you do not have admin rights, configuring crash logging would certainly be difficult. If you can, I would suggest you reach out to the admin who does have those rights and ask them to get it setup for you. The folders you showed there look about standard for the application while running, and immediately after a fresh startup.

I do hope that the crashing subsides and the recovery continues to work for you, but will keep an eye out for further reports in this area from you.

Kind regards,

David.P · Post by **David.P** » Fri Feb 07, 2025 3:04 pm

Windows just crashed.

This time, Autorecovery did not work. Although I had set it to Save AutoRecover every 3 minutes, the last available entry in the Document Recovery window is more than 4 hours old and from a different file.

No time for troubleshooting, have to redo my work...

David.P · Post by **David.P** » Fri Feb 07, 2025 5:33 pm

Okay so I just lost most of my work AGAIN, and have to give up redoing it for this week. Fortunately, this is not a hard deadline...

This time Windows didn't crash and not even PDF-XChange Editor.

I was just going to save my file, but got an error message by PDF-XChange Editor that the file "could not be saved" or similar.

Seconds later the PDF document crashed. But not PDF-XChange Editor, which kept running with another document open.

Because the crash was so quickly, I don't remember the exact error message, but it was similar to what you get when the file is locked by another process and therefore cannot be saved.

In order to preserve the contents of the temp folder I then killed PDF-XChange Editor via Task Manager.

The following is absolutely everything with a date of today in the temp folder of PDF Exchange Editor
(C:\Users\[Username]\AppData\Local\Temp\PDFXEdit.Portable)

It can be seen that nothing at all has been saved later than around 3pm, while the latest crash was about 6pm.

The document recovery window shows exactly the same as after the previous crash:

How is that even possible when I have set Auto Recovery to save every 3 minutes?

This is the contents of PDFXRecoveryInfo.xml, anonymized:

<?xml version="1.0" encoding="UTF-8"?>
<body>
<file title="2019 AB123456789 - ACME Analysis + Inspection" fs="default" path="C:\Users\[Username]\OneDrive - ACME.com\SW\Some path with some name\Some sub folder\V12345 AB123456789 ACME Type Standard 13 1-Steps-Current\2019 AB123456789 - ACME Analysis + Inspection.pdf" date="133832154410000000" size="57721704" MD5="32AAD5772AD7E532FD8A0332B73F43CC" ClosedWithoutSave="0"/>
</body>

Program version information:

Sat Feb 08, 2025 12:31 am

Hello, David.P

I will admit that at this point, I am lost as to what could be causing this. It should not be possible for a "document" to crash. If one file closes spontaneously, it would always be accompanied by an error message informing why with a statement to the effect of "the document will now be closed", prompting you to click ok.
It is possible that you pushed enter, or misclicked on the accept button which caused this to bypass you before you could read it, but this does not sounds like a situation in which autorecovery could have an impact. If the original file has been detected as changed, we cannot apply those changes to the file, closing that popup would commit to the action of closing the file normally, and in turn removing the autorecovery backup information, since we know it cannot be used.

Regardless of the possibilities, I have raised this with the Dev team for input, to see what, if anything can be done in such a situation... I know we are working on a system to help prevent users from trying to work on or make changes to a file which is in use, which would help to prevent this particular case, but otherwise, I am sorry to say that there is not likely any recovery data present if the Editor itself did not crash before the file was closed.

We did note that this appears to be a OneDrive folder, can you confirm if the file remained present locally? This issue may have been caused by a timeout and the OneDrive sync function either overwriting the original, or simply removing the file from your device. Have you ever experienced the same with a local file, and can you reproduce it on in the onedrive location?

Kind regards,