Crashing every time: Exception Code c00000fd

[grenxing]

Since about 2 - 3 weeks FreeFileSync crashes and Windows shows the following message:

--------------------
Problemsignatur:
Problemereignisname: APPCRASH
Anwendungsname: FreeFileSync_Win32.exe
Anwendungsversion: 6.13.0.0
Anwendungszeitstempel: 00000000
Fehlermodulname: ntdll.dll
Fehlermodulversion: 6.1.7601.18247
Fehlermodulzeitstempel: 521ea91c
Ausnahmecode: c00000fd
Ausnahmeoffset: 00052c26
Betriebsystemversion: 6.1.7601.2.1.0.256.48
Gebietsschema-ID: 1031
Zusatzinformation 1: c8b2
Zusatzinformation 2: c8b25d0302d9a45a5f4f7cdfa2d51ed8
Zusatzinformation 3: 5899
Zusatzinformation 4: 589959acb82195836d8b4281062139be

Lesen Sie unsere Datenschutzbestimmungen online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0407

Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie unsere Datenschutzbestimmungen offline:
C:\Windows\system32\de-DE\erofflps.txt
--------------------
In former versions all worked fine. I'm not sure but mybe the Problem exists since Version 6.12 or 6.13.

Any idea?

Thanks
Gregor

[Zenju]

I've created a 32-bit debug version of FFS. Are you able to reproduce the crash with this version?

[404, Invalid URL: https://freefilesync.org/FFS_6.13_dbg.zip]

[grenxing]

Thanks.

I'm away on business and will try in a few days.

Gregor

[grenxing]

FFS crashes with this debug version, too.

[grenxing]

I detected 2 files sync.ffs_lock having a current timestamp in the root directory of the synced directories. These and the sync.ffs_db files I attached to this post.

I don't know about the content of the files. Thus I send you a password by mail.

[Attachment was removed! File name: FFS_6_13_debug.zip (700773 bytes)]

[Zenju]

Can you send a screenshot of the crash dialog? Does it generate a crash dump file? If so, please send this file to me via email.

[grenxing]

I attached the sreenshot, but i cannot find a crash dump file (searched the whole drive for files having a current timestamp).

Do you have a hint where to search for it somewhere else?

[Zenju]

I attached the sreenshot, but i cannot find a crash dump file (searched the whole drive for files having a current timestamp).

Do you have a hint where to search for it somewhere else?

Usually the crash dump file should be created automatically and you would also see a confirmation message box. For some reason this does not work, so let's try something else:

If you haven't already, download ProcessExplorer, then reproduce the crash with FFS and stay on the crash dialog shown in your screenshot, start ProcessExplorer, right-click on the FreeFileSync_win32.exe, select "Create Dump" and then "full dump". Next, compress this file and send it to me. This should help me find out what FFS was doing during the crash.

[grenxing]

Oops, I found a file (in folder Desktop), but unfortunately the size is 0.

[Zenju]

Oops, I found a file (in folder Desktop), but unfortunately the size is 0.

Okay, zero-sized file definitively contains no information :)

[grenxing]

I created crash dump files by Process Explorer as described. The compressed file has 46 MB. I'm uploading it to my cloud and send you the link if the upload is complete.

[Zenju]

Thanks, I'm able to open the dump file. Unfortunately I don't see a particular issue. This could be related to the way how you created the dump file, namely when the windows crash dialog was shown: This means the internal state of the program is not at the location anymore of whatever triggered the crash.
What probably would have helped is the "Ausnahmeoffset", or even better the complete information of the windows crash dialog.

Can you please reproduce the crash again and then post the dump file as well as the windows crash information?

[grenxing]

I add FreeFileSync_full_dump_3_4 to my cloud directory.

And here is the information of the windows crash dialog:

Problemsignatur:
Problemereignisname: APPCRASH
Anwendungsname: FreeFileSync_Win32.exe
Anwendungsversion: 6.13.0.0
Anwendungszeitstempel: 54d7b975
Fehlermodulname: ntdll.dll
Fehlermodulversion: 6.1.7601.18247
Fehlermodulzeitstempel: 521ea91c
Ausnahmecode: c0000005
Ausnahmeoffset: 000576ab
Betriebsystemversion: 6.1.7601.2.1.0.256.48
Gebietsschema-ID: 1031
Zusatzinformation 1: e8ad
Zusatzinformation 2: e8adce1c2b9e7be834b4063ac3c53863
Zusatzinformation 3: e8ad
Zusatzinformation 4: e8adce1c2b9e7be834b4063ac3c53863

Lesen Sie unsere Datenschutzbestimmungen online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0407

Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie unsere Datenschutzbestimmungen offline:
C:\Windows\system32\de-DE\erofflps.txt

[Zenju]

I add FreeFileSync_full_dump_3_4 to my cloud directory.

And here is the information of the windows crash dialog:

Problemsignatur:
Problemereignisname: APPCRASH
Anwendungsname: FreeFileSync_Win32.exe
Anwendungsversion: 6.13.0.0
Anwendungszeitstempel: 54d7b975
Fehlermodulname: ntdll.dll
Fehlermodulversion: 6.1.7601.18247
Fehlermodulzeitstempel: 521ea91c
Ausnahmecode: c0000005
Ausnahmeoffset: 000576ab
Betriebsystemversion: 6.1.7601.2.1.0.256.48
Gebietsschema-ID: 1031
Zusatzinformation 1: e8ad
Zusatzinformation 2: e8adce1c2b9e7be834b4063ac3c53863
Zusatzinformation 3: e8ad
Zusatzinformation 4: e8adce1c2b9e7be834b4063ac3c53863

Lesen Sie unsere Datenschutzbestimmungen online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0407

Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie unsere Datenschutzbestimmungen offline:
C:\Windows\system32\de-DE\erofflps.txt

I only see "FreeFileSync_full_dump.zip" in your cloud dir. Can you send me the link to the new "FreeFileSync_full_dump_3_4.zip"?

[grenxing]

I only see "FreeFileSync_full_dump.zip" in your cloud dir. Can you send me the link to the new "FreeFileSync_full_dump_3_4.zip"?

Sorry, I forgot to share the file. Now you should see it.

[pratista]

I uninstall the 6.14 version and all the related file in the folders.
Then install the 6.13 version – same error result.
I do the same with the 6.12, 6.11, 6.10 version- all the same error return massage.

Then I install old version that I have, version 4.1
It running well and no error massage from windows.

[Zenju]

@Gregor, @Singgih:
Thanks for the latest dump file and windows crash information. I'm now able to identify the code location where the crash is happening, but the call stack is corrupted. Therefore it's hard to analyze further, but I could find out that the crash occured in the routine that created the mini dump file automatically. This is one step after the original crash and covers up the real issue. I suspect the stack corruption to be caused by the failed handling of the original crash.

Therefore I have removed the automatic dump file creation that was not working anyway and created a new test version. For you nothing has changed: You should still see a crash, I again need the dump file (and the win32 error information, just in case...) and hopefully we get a non-corrupted call stack this time:

[404, Invalid URL: https://freefilesync.org/FFS_6.13_dbg2.zip]

[grenxing]

@Gregor, @Singgih:
Thanks for the latest dump file and windows crash information. I'm now able to identify the code location where the crash is happening, but the call stack is corrupted. Therefore it's hard to analyze further, but I could find out that the crash occured in the routine that created the mini dump file automatically. This is one step after the original crash and covers up the real issue. I suspect the stack corruption to be caused by the failed handling of the original crash.

Therefore I have removed the automatic dump file creation that was not working anyway and created a new test version. For you nothing has changed: You should still see a crash, I again need the dump file (and the win32 error information, just in case...) and hopefully we get a non-corrupted call stack this time:

[404, Invalid URL: https://freefilesync.org/FFS_6.13_dbg2.zip]

I uploaded the new crash dump files (FreeFileSync_full_dump_5_6.zip) and shared it :-)

This is the information shown in the windos crash dialog:

Problemsignatur:
Problemereignisname: APPCRASH
Anwendungsname: FreeFileSync_Win32.exe
Anwendungsversion: 6.13.0.0
Anwendungszeitstempel: 54e082df
Fehlermodulname: ntdll.dll
Fehlermodulversion: 6.1.7601.18247
Fehlermodulzeitstempel: 521ea91c
Ausnahmecode: c00000fd
Ausnahmeoffset: 00058472
Betriebsystemversion: 6.1.7601.2.1.0.256.48
Gebietsschema-ID: 1031
Zusatzinformation 1: f542
Zusatzinformation 2: f5420f35e1229c49f766df633fb5278e
Zusatzinformation 3: d503
Zusatzinformation 4: d5030f3074ed04abee64297c6a3a1259

Lesen Sie unsere Datenschutzbestimmungen online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0407

Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie unsere Datenschutzbestimmungen offline:
C:\Windows\system32\de-DE\erofflps.txt

[Zenju]

Thanks Gregor, the new dump file helped a lot:
It turns out the crash is caused by an out-of-stack space issue due to an endless directory recursion. This also explains why the automatic mini dump creation facility failed.
The reason for this endless recursion is that FFS at one point finds a folder with empty name (such a folder cannot exist!) and doesn't handle this case of data corruption very well.

So there are two aspects to resolution:

Todo for FFS: I'll add a little in-expensive check to ease trouble-shooting and to fail early from now on when this peculiar problem happens again.

Todo for you: It's not clear why FFS receives data from the OS about a folder with an empty name. Obviously there is data corruption somewhere. The item I'm speaking of is a sub-folder of "H:\GmbH\Buchhaltung\DATEV_Sicherung\Weiss_u_P\2002\" and it has creation and modification date of "2003-11-18 0:25:44":


- Is there something special or noteworthy when you browse into "H:\GmbH\Buchhaltung\DATEV_Sicherung\Weiss_u_P\2002\", e.g. any strange items or some other item with the creation date above that was somehow misinterpreted?

- Can you reproduce the crash when you use "H:\GmbH\Buchhaltung\DATEV_Sicherung\Weiss_u_P\2002\" directly as base folder and start comparison?

- If you can reproduce the crash: Temporarily rename or delete "bin/FindFilePlus_Win32.dll" and see if you can still reproduce the crash.

- Is this data located on a USB memory stick? If so, can you run the Windows error check on the stick and see if it finds any problems?

[grenxing]

Thanks Gregor, the new dump file helped a lot:
It turns out the crash is caused by an out-of-stack space issue due to an endless directory recursion. This also explains why the automatic mini dump creation facility failed.
The reason for this endless recursion is that FFS at one point finds a folder with empty name (such a folder cannot exist!) and doesn't handle this case of data corruption very well.

So there are two aspects to resolution:

Todo for FFS: I'll add a little in-expensive check to ease trouble-shooting and to fail early from now on when this peculiar problem happens again.

Todo for you: It's not clear why FFS receives data from the OS about a folder with an empty name. Obviously there is data corruption somewhere. The item I'm speaking of is a sub-folder of "H:\GmbH\Buchhaltung\DATEV_Sicherung\Weiss_u_P\2002\" and it has creation and modification date of "2003-11-18 0:25:44":


- Is there something special or noteworthy when you browse into "H:\GmbH\Buchhaltung\DATEV_Sicherung\Weiss_u_P\2002\", e.g. any strange items or some other item with the creation date above that was somehow misinterpreted?

- Can you reproduce the crash when you use "H:\GmbH\Buchhaltung\DATEV_Sicherung\Weiss_u_P\2002\" directly as base folder and start comparison?

- If you can reproduce the crash: Temporarily rename or delete "bin/FindFilePlus_Win32.dll" and see if you can still reproduce the crash.

- Is this data located on a USB memory stick? If so, can you run the Windows error check on the stick and see if it finds any problems?

Hi Zenju,

I think we are on the right way.

-1- Indeed there is a problem with a folder in the mentioned directory:

Drive G: is a Samba drive at my Linux server.

The folder name at the server is:
20031117 Weiá&P
hex:
0000000 2 0 0 3 1 1 1 7 sp W e i a & P nl
32 30 30 33 31 31 31 37 20 57 65 69 e1 26 50 0a

I think, the problem is the 13th Character "e1" (the German "ß").

It seems that Windows doesn't recognize the folder name as a valid name and sets it to "".
Unfortunately the same folder name is shown again when entering der folder with the corrupted name and so on. This causes the endless directory recursion (see screenshot_1).

For comparison: At the local sync directory at drive C: the character e1/ß is substituted by an underline character and the folder name is "20031117 Wei__&P" (screenshot_2).


-2- The crash can be reproduced when I use "H:\GmbH\Buchhaltung\DATEV_Sicherung\Weiss_u_P\2002\" directly as base folder.

I added FreeFileSync_full_dump_7_8.zip to my cloud directory and shared it.

This is the information shown in the windos crash dialog:

Problemsignatur:
Problemereignisname: APPCRASH
Anwendungsname: FreeFileSync_Win32.exe
Anwendungsversion: 6.13.0.0
Anwendungszeitstempel: 54e082df
Fehlermodulname: ntdll.dll
Fehlermodulversion: 6.1.7601.18247
Fehlermodulzeitstempel: 521ea91c
Ausnahmecode: c00000fd
Ausnahmeoffset: 00058472
Betriebsystemversion: 6.1.7601.2.1.0.256.48
Gebietsschema-ID: 1031
Zusatzinformation 1: f542
Zusatzinformation 2: f5420f35e1229c49f766df633fb5278e
Zusatzinformation 3: d503
Zusatzinformation 4: d5030f3074ed04abee64297c6a3a1259

Lesen Sie unsere Datenschutzbestimmungen online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0407

Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie unsere Datenschutzbestimmungen offline:
C:\Windows\system32\de-DE\erofflps.txt


-3- I renamed the file bin/FindFilePlus_Win32.dll and the crash could be reproduced.

I added FreeFileSync_full_dump_9_10.zip to my cloud directory and shared it.

This is the information shown in the windos crash dialog:

Problemsignatur:
Problemereignisname: APPCRASH
Anwendungsname: FreeFileSync_Win32.exe
Anwendungsversion: 6.13.0.0
Anwendungszeitstempel: 54e082df
Fehlermodulname: ntdll.dll
Fehlermodulversion: 6.1.7601.18247
Fehlermodulzeitstempel: 521ea91c
Ausnahmecode: c00000fd
Ausnahmeoffset: 00058472
Betriebsystemversion: 6.1.7601.2.1.0.256.48
Gebietsschema-ID: 1031
Zusatzinformation 1: 75bc
Zusatzinformation 2: 75bce392ff9d4ae91dc76810e8d0c688
Zusatzinformation 3: e21f
Zusatzinformation 4: e21f488307187eb20f8f86259339f697

Lesen Sie unsere Datenschutzbestimmungen online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0407

Wenn die Onlinedatenschutzbestimmungen nicht verfügbar sind, lesen Sie unsere Datenschutzbestimmungen offline:
C:\Windows\system32\de-DE\erofflps.txt

-4- Because the affected drive is a samba drive i cannot run the Windows error check.
I tried to copy the folder to an USB stick, but linux gave me an error message.


-5- Besides 2002 there is a directory 2003 similar to 2002 (including subdirectory with e1/ß in it's name).
I took it as base folder and could reproduce the crash.
I replaced the e1/ß in the subdirectory by the characters "sz" and FFS worked fine.
Thus I could show that indeed the e1/ß in the subdirectory name makes the trouble.

-6- In all above tests I used your FFS_6.13_dbg2 version.

[Zenju]

So the root cause of the invalid item with empty name is a problem in the Windows network layer that has trouble to translate the Linux name. I'm not sure if the german ß is really the (only) problem: a dirname ending with newline is certainly also a recipe for problems. Anyway, the solution in this case is to change the folder name on the Linux side. As far as FFS goes, the best it can do is not crash, but show and error message instead, which is what I have just implemented for the next release.

[grenxing]

So the root cause of the invalid item with empty name is a problem in the Windows network layer that has trouble to translate the Linux name. I'm not sure if the german ß is really the (only) problem: a dirname ending with newline is certainly also a recipe for problems. Anyway, the solution in this case is to change the folder name on the Linux side. As far as FFS goes, the best it can do is not crash, but show and error message instead, which is what I have just implemented for the next release.

Thanks.

I wait for FFS 6.15 and than check the error message. After that I'll clear my directory names and FFS should work fine.

[Zenju]

No need to wait; here's the new beta version for testing:
[404, Invalid URL: https://freefilesync.org/FreeFileSync_6.15_beta_Windows_Setup.exe]

[grenxing]

No need to wait; here's the new beta version for testing:
[404, Invalid URL: https://freefilesync.org/FreeFileSync_6.15_beta_Windows_Setup.exe]

Using the beta version I got a message like shown in the attachment for all directories that contained files or directories having a German Umlaut in it's name. After correcting the mistyped names FFS worked fine.

Thanks a lot.

[ragondin]

Hello,
I'm using the latest release of FFS 6.14 and it crashes (freezes) every time I try to synchronize from or to a specific drive letter. For example, when I try to sync from F:\toto to C:\tata, it freezes.
Moreover when I synchronize from C:\toto to C:\tata, there's no problem.

The eventviewer is telling this (sorry french) :
Nom de l’application défaillante FreeFileSync_x64.exe, version : 6.14.0.0, horodatage : 0x54da455c
Nom du module défaillant : FreeFileSync_x64.exe, version : 6.14.0.0, horodatage : 0x54da455c
Code d’exception : 0xc000041d
Décalage d’erreur : 0x0000000000454483
ID du processus défaillant : 0xe10
Heure de début de l’application défaillante : 0x01d0697ca2564ad1
Chemin d’accès de l’application défaillante : C:\Program Files\FreeFileSync\Bin\FreeFileSync_x64.exe
Chemin d’accès du module défaillant: C:\Program Files\FreeFileSync\Bin\FreeFileSync_x64.exe
ID de rapport : fa05730a-d56f-11e4-bb4f-ac9e1781e39f

and the details :
FreeFileSync_x64.exe
6.14.0.0
54da455c
FreeFileSync_x64.exe
6.14.0.0
54da455c
c000041d
0000000000454483
e10
01d0697ca2564ad1
C:\Program Files\FreeFileSync\Bin\FreeFileSync_x64.exe
C:\Program Files\FreeFileSync\Bin\FreeFileSync_x64.exe
fa05730a-d56f-11e4-bb4f-ac9e1781e39f

when I was using a 32bits windows there was no problem, now it's a fresh version of 64bits windows 7. Maybe there's something behind this ?

What can I do to make it works again, as this software is awesome to sync directories ! ^^

Max

[Zenju]

Hello,
I'm using the latest release of FFS 6.14 and it crashes (freezes) every time I try to synchronize from or to a specific drive letter. For example, when I try to sync from F:\toto to C:\tata, it freezes.
Moreover when I synchronize from C:\toto to C:\tata, there's no problem.

The eventviewer is telling this (sorry french) :
Nom de l’application défaillante FreeFileSync_x64.exe, version : 6.14.0.0, horodatage : 0x54da455c
Nom du module défaillant : FreeFileSync_x64.exe, version : 6.14.0.0, horodatage : 0x54da455c
Code d’exception : 0xc000041d
Décalage d’erreur : 0x0000000000454483
ID du processus défaillant : 0xe10
Heure de début de l’application défaillante : 0x01d0697ca2564ad1
Chemin d’accès de l’application défaillante : C:\Program Files\FreeFileSync\Bin\FreeFileSync_x64.exe
Chemin d’accès du module défaillant: C:\Program Files\FreeFileSync\Bin\FreeFileSync_x64.exe
ID de rapport : fa05730a-d56f-11e4-bb4f-ac9e1781e39f

and the details :
FreeFileSync_x64.exe
6.14.0.0
54da455c
FreeFileSync_x64.exe
6.14.0.0
54da455c
c000041d
0000000000454483
e10
01d0697ca2564ad1
C:\Program Files\FreeFileSync\Bin\FreeFileSync_x64.exe
C:\Program Files\FreeFileSync\Bin\FreeFileSync_x64.exe
fa05730a-d56f-11e4-bb4f-ac9e1781e39f

when I was using a 32bits windows there was no problem, now it's a fresh version of 64bits windows 7. Maybe there's something behind this ?

What can I do to make it works again, as this software is awesome to sync directories ! ^^

Max

This sounds like you are running Windows 7 without SP1!
viewtopic.php?t=55

[ragondin]

Yes this was the problem !
Thank you for the trick :)