BUG: Starting FreeFileSync.exe from another process yields Error Code 32

[critternyc]

Attempting to run FreeFileSync.exe from another process on Windows yields the following error:

---------------------------
FreeFileSync - An exception occurred
---------------------------
Cannot open file "GlobalSettings.xml".

Error Code 32: The process cannot access the file because it is being used by another process. (CreateFile)

This does not occur from a batch file but does occur when run from another EXE. I found the issue while packaging the PortableApps.com Format package of the app and thought it may be due to an interaction with our launcher, but created a simplified NSIS-based EXE that only does one thing (ExecWait '$EXEDIR\FreeFileSync.exe') and it yields the above error as well. We may be able to code around it in our package, but I'd wager this will cause issue when run from some other scheduling software and alternate Windows Start menus.

POSSIBLE WORKAROUND: You may be able to work around this issue by creating a batch file and launching FreeFileSync from that. Create a file called freefilesync.bat in your ffs folder and have the contents be:

START /b FreeFileSync.exe

Note that this may or may not work when launched from another process like a third party menu, third party file manager or third party scheduling utility. Credit to volpoca on the PortableApps.com forum for coming up with this workaround in January 2015.

BUG REPRODUCTION: I created a set of EXEs to demonstrate the bug in February 2015 and posted them in this thread: viewtopic.php?t=1716&start=25#p6995

[critternyc]

This bug is still present in the 6.4 release.

[dragonetti]

I just started with FreeFileSync, and I think I have encountered the same "bug".
I use the program QuickMacros to make my own mini-applications/macros, when I run the command-line batch command described in the help-file through QuickMacros I get the same error described by John T. When I run the same command through windows CMD (command-line) then everything works.

Is there anything I can do to work around this? Or will this be resolved in the next version?

[ralatsf]

Same for me. Attempting to start FreeFileSync 6.3 or 6.4 (portable install on a USB Flash Drive) via my application launcher ASuite gives:

Cannot open file "GlobalSettings.xml".
Error Code 32: The process cannot access the file because it is being used by another process. (CreateFile)

[Zenju]

Does the problem also occur with the 6.5 beta?
[404, Invalid URL: http://freefilesync.sourceforge.net/FreeFileSync_6.5_beta_Windows_Setup.exe]

[dragonetti]

@Zenju
When I am in code edit mode in my program 'Quick Macros' and I run a simple command to start freefilesync.exe then it works (6.5 beta).
This was not the case in the 6.4 version, there I got the error:
Cannot open file "GlobalSettings.xml".

But I still get the error when I compile the command from the program 'Quick Macros' to an executable. Maybe my issue is more related to 'Quick Macros', I do not know.

EDIT 1:
And now it seems to work!
I have no idea what caused it not to work and then working again.
To clarify => At this moment I have no errors anymore (no errors when working from my application 'Quick Macros' and when I compile to executable).


EDIT 2:
And now the compiled executable that starts 'freefilesync' doesn't work anymore. (It still does work when I am in code edit mode in my 'Quick Macros' application).
So it's back to the original situation like I stated in the beginning of this post. (Sorry for this second edit).

[critternyc]

The error still occurs in 6.5 beta when run within the FFS Portable PA.c Format package or when a standard portable install directly from the 6.5 beta installer is run from the PA.c Platform's menu. Same error as reported above.

[bovender]

I have the same problem, running FFS 6.4 from a USB stick with PortableApps on Windows. Reverted to 6.3, works fine.

[critternyc]

This issue persists in FreeFileSync 6.5. Downloading the official Windows installer from here and installing in portable mode. When attempting to run it from the PortableApps.com Menu, we still get Error Code 32. FFS in portable mode still can't be launched from an external EXE (an app launcher, a scheduler, etc).

[silverray]

Same for me on FFS 6.6 on wPP and PA
back to 6.3

[critternyc]

The issue persists in FFS 6.6. Starting FreeFileSync.exe via another process still produces the above error, so it can only be started via Windows Explorer, a shortcut, command line, or a batch file.

[blues12]

Confirmed. Same here. Still not fixed.

[critternyc]

This bug is still present in FreeFileSync 6.7. The app simply can not be run from other menus, scheduling apps, etc.

[oxsmos]

Should diff between versions 6.2 and 6.3...that are respectively the last good and first bad with this issue

[critternyc]

I did a quick skim of the diff between 6.2 and 6.3 and nothing jumped out at me. Granted, I haven't determined where in the code this error is being thrown incorrectly. Perhaps someone with better C++ chops could take a look or the author could point us to where this invalid error is being thrown from.

[silverray]

I'm getting the same error in ffs 6.8

[critternyc]

This bug is still present in FreeFileSync 6.9. Anyone more versed in C++ than me care to take a stab at examining the DIFF between FFS 6.2 and 6.3 and determine how the bug was introduced?

[critternyc]

If it helps at all, the error is occurring within freefilesync.exe. Substituting that file from 6.2 into 6.3 fixes the error. So the error is in the code of this 'shortcut' exe instead of within the main EXEs that it calls within Bin.

[bono82]

Same error here. We use the installed version, not portable. Everything worked fine until we upgraded to 6.10. We use a scheduled script which call FreeFileSync with parameter(.ffs_batch). Now we get the following error message(see attached screenshot): "Cannot open file "GlobalSettings.xml".
Error Code 32: The process cannot access the file because it is being used by another process. (ReadFile)". We uninstalled it and installed the last "good" version (6.9), but unfortunately the problem is same. I tried to copy the .exe from version 6.2 as John suggested, but it did not help.

I tried to call FreeFileSync_Win32.exe directly from the script, but it did not help.

Anyone has another idea?

[critternyc]

Yes, this affects the app in 'installed' mode as well as portable. So, you can't run it from anything else except Explorer or the Windows Start/Tile Menu.

[bono82]

Yes, but it is strange, because sometimes it workes from TaskScheduler, but mostly doesn't. I don't know what is the difference.

[critternyc]

FreeFileSync 6.11 fails about 1/2 the time when launched from another EXE. There doesn't appear to be any rhyme or reason to why it fails some times but not others.

[jwayfarer]

Bug is still present on FreeFileSync 6.12.

Tested on Windows 7 Professional x64 Spanish, fully updated, using the following apps as launchers:

- PortableApps.com Platform 12.0.5 -> Fail
- CubicExplorer 0.95.1 Portable -> Fail
- Console 2.00.148 Portable -> Fail
- Explorer++ 1.3.5.531 Portable -> Fail
- Process Hacker 2.33 Portable (Run dialog) -> Fail

Strangely, sometimes it does not fail, though I have not been able to find a specific reason for that. Launching FreeFileSync.exe through a .cmd file with only one line "cmd /c FreeFileSync.exe" fails also.

May it be an antivirus issue? It's sooo strange...

[fractals]

As FreeFileSync is open source, would it be possible to run it and step through the code with a debugger to find precisely where it is failing?

I really like FreeFileSync Portable. Version 6.2 still seems to work well, but it would be really nice to be able to use a newer version, as 6.2 is about a year old now.

[b8375629]

Looks like this is abandonware since it's been almost a year since this issue has been addressed and Zenju has said anything about it.

Not to mention this is being now being flagged as malware since ESET reports a Win32/FusionCore.A infection in it's .exe file.

Could well be looking for an alternative for this.

[bennieboj]

Well Zenju responded once on this thread so he tried, but most likely does not care enough about this. yet he responded to another topic about 5 days ago. Maybe the flag by ESET could be a false positive?

[bennieboj]

I've been looking in to this atm.
I cannot build FFS, I never tried to build it only have msvs2012 installed at the moment and I'm having problems with a file "wx+\pch.cpp" not being found. Anyhow, I digged through some of the code from 6.2 and 6.3. I diffed all the files using WinMerge but I couldn't make much out of the changed things (just to much changes, not familiar with the code etc).


Then since the error mentioned not something about not being able to open a file *GlobalSettings.xml*, I started grepping on the 6.3 code. I found it wasn't used as a literal, but most as the xmlAccess::getGlobalConfigFile() function in lib/process_xml.cpp.
Of course it is possible that another variable holds the same filename inside some of the settings files, but this is the only direct reference grep could find.
So we know: look for getGlobalConfigFile().

Then I grepped on *"Cannot open file"*, lots of references mostly in unimportant language files, some in application.cpp unrelated to our xml file (no mention of getGlobalConfigFile()) one important one in file zen/file_io.cpp in the FileInput function.

Next question, do we get from the application.cpp file to the file_io.cpp file? TL;DR: yes.
Long version: The *runBatchMode* function in application.cpp calls *readConfig(getGlobalConfigFile(), globalCfg, warningMsg)* which is a call to void *xmlAccess::readConfig(const Zstring& filename, xmlAccess::XmlGlobalSettings& cfg, std::wstring& warningMsg)* in process_xml.cpp which calls *void readConfig(const Zstring& filename, XmlType type, ConfigType& cfg, int currentXmlFormatVer, std::wstring& warningMsg)* in the same file with the correct parameters. Sorry for the long function definition copy pastes, but the file contains a lot of fuctions named "readConfig", so better safe than sorry.
Now this template function calls loadXmlDocument(const Zstring& filename) from zen/xml_io.cpp., which on his turn uses the FileInput function mentioned earlier.

So I *think* I found where the error occurs, just not why, or what made build starting from 6.3 break when called from another process. The only thing changed from 6.2 to 6.3 related to these files I just mentioned are in *file.io.cpp*. There are other edits in the code but they are not executed until after the crash I believe. The main thing that changed in file_io.cpp is the addition of Source-Code Annotation Language (_In_ and _In_opt_) at the CreateFile call which aren't interpreted by the compiler anyhow IIRC.

This was my 2 cents, hope this gets fixed soon. I'm willing to test debug versions and offer dumps of all kinds (like I did last time) if I have time :D

[b8375629]

Well Zenju responded once on this thread so he tried, but most likely does not care enough about this. yet he responded to another topic about 5 days ago. Maybe the flag by ESET could be a false positive?

Yeah, that was months ago. If he cared, he'd fix it.

I tried testing this in a sandbox and it still wouldn't let me load, giving me a 'runtime error message'

Nope, I'm afraid this is done. Best to look for alternatives out there. Do you have any you'd recommend?

[Zenju]

I've been looking in to this atm.
I cannot build FFS, I never tried to build it only have msvs2012 installed at the moment and I'm having problems with a file "wx+\pch.cpp" not being found. Anyhow, I digged through some of the code from 6.2 and 6.3. I diffed all the files using WinMerge but I couldn't make much out of the changed things (just to much changes, not familiar with the code etc).


Then since the error mentioned not something about not being able to open a file *GlobalSettings.xml*, I started grepping on the 6.3 code. I found it wasn't used as a literal, but most as the xmlAccess::getGlobalConfigFile() function in lib/process_xml.cpp.
Of course it is possible that another variable holds the same filename inside some of the settings files, but this is the only direct reference grep could find.
So we know: look for getGlobalConfigFile().

Then I grepped on *"Cannot open file"*, lots of references mostly in unimportant language files, some in application.cpp unrelated to our xml file (no mention of getGlobalConfigFile()) one important one in file zen/file_io.cpp in the FileInput function.

Next question, do we get from the application.cpp file to the file_io.cpp file? TL;DR: yes.
Long version: The *runBatchMode* function in application.cpp calls *readConfig(getGlobalConfigFile(), globalCfg, warningMsg)* which is a call to void *xmlAccess::readConfig(const Zstring& filename, xmlAccess::XmlGlobalSettings& cfg, std::wstring& warningMsg)* in process_xml.cpp which calls *void readConfig(const Zstring& filename, XmlType type, ConfigType& cfg, int currentXmlFormatVer, std::wstring& warningMsg)* in the same file with the correct parameters. Sorry for the long function definition copy pastes, but the file contains a lot of fuctions named "readConfig", so better safe than sorry.
Now this template function calls loadXmlDocument(const Zstring& filename) from zen/xml_io.cpp., which on his turn uses the FileInput function mentioned earlier.

So I *think* I found where the error occurs, just not why, or what made build starting from 6.3 break when called from another process. The only thing changed from 6.2 to 6.3 related to these files I just mentioned are in *file.io.cpp*. There are other edits in the code but they are not executed until after the crash I believe. The main thing that changed in file_io.cpp is the addition of Source-Code Annotation Language (_In_ and _In_opt_) at the CreateFile call which aren't interpreted by the compiler anyhow IIRC.

This was my 2 cents, hope this gets fixed soon. I'm willing to test debug versions and offer dumps of all kinds (like I did last time) if I have time :D

so far it seems this problem is only occurring in the context of PortableApps and not when starting normally from Windows Explorer. Most likely it is caused by some conflict with the PA configuration handling on startup that makes applications portable.

[critternyc]

so far it seems this problem is only occurring in the context of PortableApps and not when starting normally from Windows Explorer. Most likely it is caused by some conflict with the PA configuration handling on startup that makes applications portable.

Hi Zenju. I've been looking at this bug for a while. It's nothing to do with our packaging. Even when running your standard portable version installed from your installer directly with none of our added bits from the PortableApps.com Menu... which does nothing but run an EXE directly... it produces the mentioned error. The code being executed when a user runs FFS from our menu is only this (replacing the actual strings for the internal variables for readability:

ShellExecute(0,'open', PChar('P:\PortableApps\FFS\FreeFileSync.exe'+#0),Nil, PChar('P:\PortableApps\FFS'+#0), SW_SHOWNORMAL);

The same error occurs for me when run from a locally-installed scheduler utility as well as when run from 3rd party file explorers. Even if you run it from an EXE that just runs FreeFileSync.exe (more on that in a minute).

It's also worth noting that the FreeFileSyncPortable.exe launcher used in our FreeFileSync Portable package was last altered/compiled in October of 2013 and worked perfectly fine up until FreeFileSync 6.3 in March of 2014 when FFS stopped working with 3rd party schedulers, file explorers, etc as well.

I explored the diffs of 6.2 to 6.3, when the issues started, and could not see anything that should be causing the issue.

I have produced an EXE with just a single line of code in NSIS to run FreeFileSync.exe and then wait for it to stop running and it produces the bug as well. You can download my simplified bug reproducer here:
http://portableapps.com/downloads/temp/FreeFileSyncBug.zip

Just place FreeFileSyncBug.exe in the same directory as FreeFileSync.exe and run it.

The bug seems to occur when the Windows process that runs FreeFileSync.exe remains running. If the process exits immediately after running FreeFileSync.exe, the bug does not seem to occur occur. To that end, I also included FreeFileSyncNoBug.exe which will Exec FreeFileSync.exe and then immediately exit. This does not produce the bug on my system. If, however, I add Sleep 10000 after the Exec to keep the exe running for 10 seconds after launching FreeFileSync.exe, the bug occurs.

I've included both EXEs as well as the source code within the above linked zip file. You can compile them yourself using NSIS Unicode Portable (or local, for that matter).

If you need any additional assistance or details, please just let me know.