BUG: Starting FreeFileSync.exe from another process yields Error Code 32
- Posts: 27
- Joined: 11 Dec 2004
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
---------------------------
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
- Posts: 27
- Joined: 11 Dec 2004
This bug is still present in the 6.4 release.
- Posts: 6
- Joined: 6 Sep 2011
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?
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?
- Posts: 6
- Joined: 27 Feb 2013
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)
Cannot open file "GlobalSettings.xml".
Error Code 32: The process cannot access the file because it is being used by another process. (CreateFile)
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
Does the problem also occur with the 6.5 beta?
[404, Invalid URL: http://freefilesync.sourceforge.net/FreeFileSync_6.5_beta_Windows_Setup.exe]
[404, Invalid URL: http://freefilesync.sourceforge.net/FreeFileSync_6.5_beta_Windows_Setup.exe]
- Posts: 6
- Joined: 6 Sep 2011
@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).
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).
- Posts: 27
- Joined: 11 Dec 2004
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.
- Posts: 1
- Joined: 12 Feb 2013
I have the same problem, running FFS 6.4 from a USB stick with PortableApps on Windows. Reverted to 6.3, works fine.
- Posts: 27
- Joined: 11 Dec 2004
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).
- Posts: 2
- Joined: 1 Jun 2014
Same for me on FFS 6.6 on wPP and PA
back to 6.3
back to 6.3
- Posts: 27
- Joined: 11 Dec 2004
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.
- Posts: 85
- Joined: 28 Aug 2012
Confirmed. Same here. Still not fixed.
- Posts: 27
- Joined: 11 Dec 2004
This bug is still present in FreeFileSync 6.7. The app simply can not be run from other menus, scheduling apps, etc.
- Posts: 2
- Joined: 27 Oct 2012
Should diff between versions 6.2 and 6.3...that are respectively the last good and first bad with this issue
- Posts: 27
- Joined: 11 Dec 2004
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.
- Posts: 2
- Joined: 1 Jun 2014
I'm getting the same error in ffs 6.8
- Posts: 27
- Joined: 11 Dec 2004
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?
- Posts: 27
- Joined: 11 Dec 2004
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.
- Posts: 4
- Joined: 13 Mar 2014
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?
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?
- Attachments
-
- FFSError.jpg (15.88 KiB) Viewed 18674 times
- Posts: 27
- Joined: 11 Dec 2004
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.
- Posts: 4
- Joined: 13 Mar 2014
Yes, but it is strange, because sometimes it workes from TaskScheduler, but mostly doesn't. I don't know what is the difference.
- Posts: 27
- Joined: 11 Dec 2004
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.
- Posts: 1
- Joined: 1 Mar 2004
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...
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...
- Posts: 26
- Joined: 8 Sep 2010
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.
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.
- Posts: 2
- Joined: 24 Jan 2015
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.
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.
- Posts: 13
- Joined: 6 Dec 2013
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?
- Posts: 13
- Joined: 6 Dec 2013
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
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
- Posts: 2
- Joined: 24 Jan 2015
Yeah, that was months ago. If he cared, he'd fix it.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 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?
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
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.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 :Dbennieboj
- Posts: 27
- Joined: 11 Dec 2004
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: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.Zenju
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.