Sorry if this is a duplicate post, but the normal resolutions for this problem have not worked for me so far.
Upon trying to launch Start.exe I am receiving a, "The PortableAppsPlatform.exe file is not a valid PortableApps.com release and can not be launched," message.
After receiving this message I can locate the actual Platform executable and start the application. However, when it attempts to initialize the updater I receive, "The PortableApps.com Updater or App Directory is already running. This could be the PortableApps.com Platform automatically checking for updates on startup. Please wait for other instances to finish before starting another."
All of the other apps that I try to start give me a generic, "Another instance of [insert app name] is starting. Please wait for it to start before launching it again."
This system has been working fine for about a year, and I only started receiving this message today. There is a possibility that the drive was removed from another system last without closing the USB out properly. I have checked the filesystem on the USB drive, but chkdsk reported no corruption on the drive.
The normal fix that I have located on the forums indicates that there is a loss of permission to the %appdata%\local\Temp folder, but that is not the case in my situation. I have Full Control to this directory, but am receiving this issue nonetheless.
Is there a temporary file created that PortableApps checks for that I may need to amend or remove to get it to launch correctly? Perhaps any registry entries that need to be removed?
I look forward to your responses, thank you.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
Follow us on Twitter
This is almost always a result of corrupt files on the drive.
To confirm, try installing the platform fresh to your Desktop directly. You can easily delete it when you're done. If it runs, then it's something with the drive. If it doesn't, it could be due to your antivirus.
Sometimes, the impossible can become possible, if you're awesome!
Thank you for the quick reply, John.
I am at work right now and do not have the rights to install applications on the local machine. (Hence, the use of PortableApps.) This will have to wait until I am at home.
However, if this USB drive does work at home, I can safely assume that this is due to changes in our Antivirus protection.
On the other hand, my computer at home (and the computer which this was removed from while in use) is on Windows 8, whereas the computer here is on Windows 7. I am not sure if there is a difference in how they lock drives or anything, but it is just something else that I thought of.
I shall report back on my findings as soon as I am able. Thank you!
Jonathan E. Styles
IT Support Analyst
You likely can "install" the PA.c Platform directly to your Desktop or My Documents directory to test with. It's not an actual install and it's just copying files which you can delete as soon as you're done.
Sometimes, the impossible can become possible, if you're awesome!
I was able to successfully install PA to my Desktop as you had suggested. However, when executing Setup.exe from the Desktop the same error is encountered.
So, I would consider it safe to assume that something on the local machine is causing these applications to act so oddly. Is there any manner of logging that we can perform to see where these applications are encountering problems?
My company is pretty good an publically-announcing any changes to firewall and security practices. There have been no announcements or changes that I am aware of over the weekend, and this worked correctly on Friday.
Do you have any further ideas/suggestions, sir?
Jonathan E. Styles
IT Support Analyst
That message means that Start.exe attempted to get the version details of the PortableAppsPlatform.exe and it failed. The only time this will fail is if the system is preventing it from accessing the DLL that is extracted to TEMP. Start.exe checks for the ability to write to TEMP on startup but doesn't currently have the ability to check for execution access.
Sometimes, the impossible can become possible, if you're awesome!
I have triple-checked and verify that I have Full Control (Full Control / Modify / Read & Execute / List Folder Contents / Read / Write all checked) to the %APPDATA%\Local\Temp directory. I confirmed that I can copy files and delete files from this folder. I also created a .txt file and opened it successfully from this folder. Unsure as to why this access is being restricted. The McAffee log files do not show that this program is being blocked.
Again, once I am at home I shall try again and see if I experience the same failure. (Will try on both Windows 8 and Windows 7 machines.)
For trial purposes, I also attempted to re-install on the USB drive that we were previously having issues with. Unfortunately, during the 'upgrade' process the installer disappears and does not seem to complete the installation. Executing from the USB drive again throws the error message.
I appreciate all of the help you have provided so far. I hope we can figure this out!
Jonathan E. Styles
IT Support Analyst
You may indeed have full control on TEMP, but a corporate antivirus can be configured to disallow executable access within TEMP without you seeing any changes on your end. This is likely why the installer failed as well.
One other possible fix to try. Create a batch file called Start.bat on your drive as well as a folder called TEMP in the root directory. Within start.bat, put the following, replacing X with the letter of your drive:
SET TEMP=X:\TEMP
SET TMP=X:\TEMP
Start.exe
That should set your TEMP for the platform and apps to the TEMP folder on your device without affecting any local apps. See if this has any affect on things. And, if you do get the error about the platform being invalid from Start.exe again, open up your X:\TEMP directory and see if there is anything in it to ensure it's actually being used.
Sometimes, the impossible can become possible, if you're awesome!
John,
As previously mentioned, I went ahead and tried this at home. My USB drive does indeed work correctly on my home systems. (Both Windows 8 and Windows 7) The issue is indeed on the computer here at work.
As you have instructed, I created the batch file as follows:
SET TEMP=E:\Temp
SET TMP=E:\Temp
E:\PA\Start.exe
However, whenever I attempt to execute this it seems to just simply kick me out to a new command prompt window. I can manually run Start.exe by typing
e:\pa\start.exeat the command prompt. (It brings up the same error we have witnessed before, though.)If you have any other ideas, please let me know. If I can discover a workaround, I will make sure to update.
John, again, thanks for all of your help!
Jonathan E. Styles
IT Support Analyst
I just saw the additional request in your response to check the TEMP folder to verify if it was empty.
I checked the folder, and it is indeed empty. The system is registering this as the current TEMP/TMP folder, though. If "%temp%" is typed at the command prompt, it does reflect as E:\Temp now.
Jonathan E. Styles
IT Support Analyst
Hi John,
I experienced the "exception ErInOut error 183" starting start.exe, but using your suggestion of the bat.file
now it works immediately again.
Now the questiones are:
1) how this new path association affects Portableapps&its_portable_apps and how affects the other legacy application?
2) what does it mean so ? what permissions do I have to check ? Whigh group or name I have to see within the Security tab
of the TEMP folder ?
Please consider this is an home win7ultimate computer where I am administrator.
Something goes wrong running a script two days ago and immediately after I got the error, but after reboot
any other application comes back to work except start.exe unfortunately.
I was thinking about, is there any kind of deep-verbose-log debug-level log it is possible
to activate in start.exe? Even command-line would be ok for me.
Thank you so much in advance,
best regards
Federico
Try installing the platform to another location, say your DESKTOP directory temporarily, and see if it works there. Not sure I can assist more deeply as this is more a Windows and permissions issue.
Sometimes, the impossible can become possible, if you're awesome!
Hi John, thank you for the answer, I already tried, not to desktop but to another drive, but no change, issue is still there.
I understand something goes wrong with windows indeed but is there any kind of deep-verbose-log debug-level log it is possible
to activate in start.exe? Even command-line would be ok for me.
Or, if not, I think you know which kind of log level I can have to activate in windows to trap logs from start.exe
Thank you so much in advance,
Federico
In that case, it's a TEMP permissions issue. There's no debugging available for Start.exe. And you'd get that error as soon as it tried to write to TEMP. I'm surprised you aren't having issues with other software on that computer.
Sometimes, the impossible can become possible, if you're awesome!
Hi John, I finally solved.
The key has been the error and sysinternal "procmon".
First of all, ErInOut error 183, if you go here:
https://docs.microsoft.com/it-it/dotnet/standard/io/handling-io-errors
you understand this is the real error:
ERROR_ALREADY_EXISTS 183 File o directory already existant.
After that, with process monitor I run start.exe, collect logs
and filtered until found operations on this path:
C:\Users\XXXXXXXX\AppData\Local\Temp\
well, one of these operations failed, with NAME COLLISION error :
C:\Users\XXXXXXXX\AppData\Local\Temp\asdfjkhasdflkjhasdfjkhasdflkjhasdflkjhasdf NAME COLLISION Desired Access: Read Data/List Directory, Synchronize, Disposition: Create, Options: Directory, Synchronous IO Non-Alert, Open Reparse Point, Attributes: N, ShareMode: Read, Write, AllocationSize: 0
So I understood....
I checked and there was a directory named "asdfjkhasdflkjhasdfjkhasdflkjhasdflkjhasdf"
and start.exe was not able to overwrite this already there.
Deleted, that's all. Start.exe works again like a charm.
That's why issue was related only to start.exe and no effects on other applications.
hoping can help others and fix in new version,
best regards,
F
That directory is only created by Start.exe to ensure TEMP is writable and then immediately deleted. Not sure how it got left there. I just added in logic to Start.exe for some edge cases like this for inclusion in the 18.0.1 locale update. Thanks for posting the details! Oddly, I can't get the error to occur on my machine by creating the directory, but I'm going to include logic to try to handle this issue for others.
Sometimes, the impossible can become possible, if you're awesome!
And thank you for your kind and fast support!!!
Cheers !
I have discovered a work-around for this matter which seems to be working for the time being.
McAfee Enterprise seems to block Temp folder access by name, searching for the wildcard *temp* in folder names for Temporary folder execution.
So, the main idea was to create a new useable temporary folder without the "Temp" name involved in it. In my case scenario, we will be utilizing the folder E:\SharkAttack\.
Here is the script (named start.bat) in all of its glory:
SET TEMP=E:\SharkAttack
SET TMP=E:\SharkAttack
E:\PA\Start.exe
When executed, this tells the system to set E:\SharkAttack\ to the system's useable Temporary folder and then executes the PortableApps Platform (which I have stored in the E:\PA\ directory.
Apparently, as John so kindly instructed, the Platform negotiates with a DLL file stored in the system Temp folder, and access to this folder is being extremely restricted by my corporation's version of McAfee.
By using this workaround I am now able to successfully use PortableApps and all of my installed applications without any problems.
NOTE: I am unsure of the effect this may have on other systems that utilize the system Temporary folder, as this seems to direct the system to use this folder for all Temp use. You may want to set your system Temp folder back to the system default when you are done using PA.
Jonathan E. Styles
IT Support Analyst
It only uses that TEMP location for the Start.exe process and all processes it launches. So, if you run IE from your Windows Start menu, it'll still use your local TEMP.
Sometimes, the impossible can become possible, if you're awesome!
Again, thank you for all of your help, sir.
This seems to be working for now, and I am very glad to have access to my critical applications once again. Hopefully this information will help anyone that is encountering this same issue.
Jonathan E. Styles
IT Support Analyst
Could you please check if directories like TMP or TEMPFiles are blocked or if it is just TEMP?
Sometimes, the impossible can become possible, if you're awesome!
As requested, I performed the same task, but instead used two batch setups: One with
E:\TMPas the directory in use, and the second withE:\TEMPFilesas the set temporary directory.The initialization utilizing
E:\TMPdid not work, and we received the same error that we encountered at the beginning of this thread.E:\TEMPFiles, however, worked fine. The PortableApps Platform and subsequent applications were able to start and operate normally.If you have any further queries, I would be glad to assist.
Jonathan E. Styles
IT Support Analyst
Thanks for checking into that, Jonathon. That will help us when setting up a default name for the TEMP directory when contained on the drive to help work around some of these issues. So, it would seem that the names TMP and TEMP are hard-coded to be restricted for running based on your checks. Based on that, we'll select a different name for the default. Once that's complete, you should be able to use the platform without needing to mess about with a BAT file.
Sometimes, the impossible can become possible, if you're awesome!
Cool. Thanks for all of the help, John! Look forward to working with you again.
Jonathan E. Styles
IT Support Analyst
I adjusted the Start process in 18.0.1 to better handle the custom directory and to test it using a unique folder name so there will never be a collision (2^122), so you shouldn't run into this again. Unless you're very very very very (un)lucky.
Sometimes, the impossible can become possible, if you're awesome!
Sorry to necro this thread, but I recently encountered a problem where the USB drive is being re-assigned drive letters on different machines. This could be a burden in some circumstances, especially when there are problems accessing text-editors on the machine you are using.
So, to circumvent this issue I have simply re-written the script to account for the drive letter it is being executed from. Here is the updated code:
SET TEMP=%~d0%\TEMPFiles
SET TMP=%~d0%\TEMPFiles
%~d0%\PA\start.exe
This seems to be working great so far. Please note that this should be a batch file stored in the root folder of the USB drive. My copy of PortableApps is being stored in the X:\PA\ folder, make sure your script points to the correct folder where you have your copy of PortableApps installed on your USB drive.
Jonathan E. Styles
IT Support Analyst
Along with the rest of the
%~family%~d0should not include a trailing %. Inclusion of the trailing % is usually not an issue as a lonely % just gets ignored, however if you're using an environment variable in your path (e.g.X:\TempFilesFor%USERNAME%, not that I'm recommending it) then it can confuse the command processor as (with the exception of%~instances) it searches for pairs of %s, which will cause it to think your intended path is an environment variable (e.g. %~d0%\TempFilesFor%USERNAME%), thus parsing it incorrectly (e.g. X:USERNAME)For reference,
CALL /?returns (in part)… If Command Extensions are enabled CALL changes as follows: … Substitution of batch parameters (%n) has been enhanced. You can now use the following optional syntax: %~1 - expands %1 removing any surrounding quotes (") %~f1 - expands %1 to a fully qualified path name %~d1 - expands %1 to a drive letter only %~p1 - expands %1 to a path only %~n1 - expands %1 to a file name only %~x1 - expands %1 to a file extension only %~s1 - expanded path contains short names only %~a1 - expands %1 to file attributes %~t1 - expands %1 to date/time of file %~z1 - expands %1 to size of file %~$PATH:1 - searches the directories listed in the PATH environment variable and expands %1 to the fully qualified name of the first one found. If the environment variable name is not defined or the file is not found by the search, then this modifier expands to the empty string The modifiers can be combined to get compound results: %~dp1 - expands %1 to a drive letter and path only %~nx1 - expands %1 to a file name and extension only %~dp$PATH:1 - searches the directories listed in the PATH environment variable for %1 and expands to the drive letter and path of the first one found. %~ftza1 - expands %1 to a DIR like output line In the above examples %1 and PATH can be replaced by other valid values. The %~ syntax is terminated by a valid argument number. The %~ modifiers may not be used with %*P.S.: I think using "SharkAttack" as the %TEMP% directory's name sounds good.
P.P.S.: I see nothing wrong with this instance of threadomancy. As you're the same person coming back at a later date with an update regarding the workaround recommended to you in this thread, I think it would have been inappropriate to start a new thread for it and anyone reading this thread due to experiencing the same or a similar issue would likely be helped by your new post.
~3D1T0R
This is an excellent resource. I did stumble across this help file including the environment variables for this task, but being the first time that I have used them I was very unclear on how to use them, and the way that I implemented them worked so I figure I was in the clear.
It is an excellent point that later combining variables could cause great confusion, I appreciate you taking the time to point this out as I would have most likely encountered issues down the road as this script generated into something more elaborate.
Thank you so much for taking the time to reply to this and pointing out these possibly critical flaws.
Return to P.S.(s) I liked "SharkAttack" myself, but John insisted that I use "TEMPFiles." for some reason. That guy is pretty persuasive!
Jonathan E. Styles
IT Support Analyst
You can now do this without a batch file in the PortableApps.com Platform 12.0.2. By creating a directory called TempForPortableApps in the same directory as Start.exe, Start.exe will now set TEMP and TMP to that path for the Platform and all apps you launch from it. Details are in the support section: https://portableapps.com/support/platform#advanced
Sometimes, the impossible can become possible, if you're awesome!
I have just updated to 12.0.2 as per your recommendation. (Just opened the PortableApps Platform and it notified me of the update.)
As per your instruction I created a new folder in my current X:\PA\ directory called TempForPortableApps. (So now there is a new tree structure of X:\PA\TempForPortableApps\)
I then proceeded to load PortableApps by simply executing X:\PA\Start.exe and it worked beautifully!
Thank you so much for this needed workaround. You guys are great!
Jonathan E. Styles
IT Support Analyst
You're welcome. I plan on enhancing it later to improve detection of TEMP issues and allow users to create and use a portable TEMP on the fly.
Sometimes, the impossible can become possible, if you're awesome!