Recently a large number of security updates were pushed for Microsoft Office at work. We have an Excel tool with a Visual Basic backbone which worked prior to the updates, and now does not work.
I have done some isolated testing and have found that we see the same 'error 75' when using the FileCopy method on .BAT and .EXE files. Other less 'risky' file types seem to be ok. This is also an issue with the 'Open' command.
Does anybody know of a workaround for this issue when copy/pasting .EXE and .BAT files, or maybe this is a known issue with a certain security update? I have searched everywhere, but the Google is failing me. I am hoping either:
Someone knows which security update is the culprit and I can try
uninstalling it to see if that fixes the issue
There is a different way to copy/open/manipulate .BAT and .EXE files that doesn't violate the new security patch.
Some background:
We are using Microsoft Office Professional Plus 2010 and the tool uses Excel as the interface.
Here is the testing code I am using. I have verified that .TXT and .DAT files run just fine while .EXE and .BAT files cause 'error 75' indicating a permissions error. And before you ask, yes, the file path is correct, I have just omitted my employee identification information.
Sub Macro1()
' Declare variables
Dim Filename, SourcePath, DestPath As String
' Pathname variables
Filename = "test.dat"
SourcePath = "C:\Users\<REDACTED>\Desktop\working_copy\" & Filename
DestPath = "C:\Users\<REDACTED>\Desktop\working_copy\test\" & Filename
' Copy file from Source and paste in Destination
FileCopy SourcePath, DestPath
End Sub
Here is an image with the updates that were installed. The tool worked prior to the 6/14/2017 dump, so anything before can be disregarded.
Sorry for the image, too many to enter them manually, no easy way to copy from the update list:
MS Office 2010 Security Updates
Nothing with the tool or file structure changed. The only thing different is the updates. Also, we tested the same tool with Microsoft Office Home 2016 and it worked without a hitch.
Any and all help will be appreciated. Thanks in advance!
While I never found a real fix for this issue, I did come up with a slightly 'hacky' work-around.
The MS security patch prevented me from copy/pasting .BAT and .EXE files, I but could still save .BAT files.
So, I ended up having my script create a text file called "copyExe.txt" which had a single line:
ECHO F|xcopy <source> <destination>
This was then renamed to be "copyExe.bat" and run.
By creating a .txt file, I circumvented the errors when using the VBA Open function on .BAT files (so I could actually create this new batch file). This batch file has the sole purpose of copy/pasting a .EXE file from one folder to another, which circumvented errors when trying to copy/paste .EXE files.
After the copy/paste script is run, it is deleted.
All-in-all it feels like a very silly solution, but it works and is very non-invasive for the user.
Related
Based on knowledge gained through working with the OpenXML SDK, I have implemented an Excel generator in JS (using TypeScript with ReactJS and a custom JSX factory generating plain XML). The files generated open fine in Excel and one can also edit and save them fine in Excel, no errors.
However, if one tries to copy cells (even a single one) from such a generated Excel file to another worksheet in the same Excel instance, it fails with the error "The command cannot be used on multiple selections.". Just saving and reopening the file is enough to fix the problem. Copying to other applications (e.g. Notepad) works fine.
It seems that this particular error is shown by Excel in several edge cases where the data is not exactly meet the expected format, for instance I found reports of that happening when a sheet is hidden when manipulating it via VBA. However, in my case I'm not sure what could be causing the issue.
Just saving the file in Excel unfortunately significantly alters its parts, so that I couldn't get a meaningful diff out of it. I did not see what could be causing the problem. Maybe someone has some experience with the internals of Excel?
To get a sample file, copy the following into your browser address bar and save it as xlsx file:
data:application/vndopenxmlformats-officedocumentspreadsheetmlsheet;base64,UEsDBBQAAAgIAAAAAAA69A4d5wAAAGYBAAAPAAAAeGwvd29ya2Jvb2sueG1sjZA9T8MwEIZ3JP7DyTt1AAmhKEkXBOqCMgC7Y1+SU/0R3bktPx+3ocxM9/k+9+qa7XfwcEQWSrFV95tKAUabHMWpVZ8fr3fPCrbd7U1zSrwfUtpDEURp1ZzzUmstdsZgZJMWjGUyJg4ml5InLQujcTIj5uD1Q1U96WAoqpVQ838YaRzJ4kuyh4AxrxBGb3KxKzMtoro/Zz3rrrmck98Ikk3GVh1JaPCoIJpQyi/CE/SHwZNdQZBGeGOcEpOJoOAi3rnyDwVcU0l45x5Vwesr3+FIEd17AUrpW+Ntz3AOZ1112b0a634AUEsDBBQAAAgIAAAAAAD2SCbhNwEAAMYCAAANAAAAeGwvc3R5bGVzLnhtbJ1STWvDMAy9D/YfjO+rk8DGGEl6KAR22aUd7OokSmvwF7Zbkv36yXFK20EZ7GJJz++9KLLK9agkOYHzwuiK5quMEtCd6YXeV/Rz1zy9UrKuHx9KHyYJ2wNAICjRvqKHEOwbY747gOJ+ZSxovBmMUzxg6fbMWwe891GkJCuy7IUpLjStS31UjQqedOaoQ0UzyupyMPqCFDQBSOUKyInLim64FK0TkevF9wLmeaxZ4qazvQBz8HghpLz1RqAuLQ8BnG6wIEu+myxUVBsNyGJXhGg2hz+ke8envHi+p54DdtQa1+PYzz3l9Awh5VeC7A6k3MYX+BpuJONA0ijf+zhFEn/3nOJ3ljTZpCLO5toteV/ZFv+yJdxaOX0cVQuumVcgNcjG4b5dftduEbKlt7rsx+F2W9hlIesfUEsDBBQAAAgIAAAAAABh+IC4iAEAAGIDAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1shZNNT8MwDIbvSPyHKCc4sGzdxsfUFsEQEhJCSOPjnKXeFtEkVWLY4NfjtKUaaBqXyLXzPn7jpOnlxpTsA3zQzmZ80OtzBla5Qttlxp+fbk/OObvMDw/StfNvYQWAjBQ2ZHyFWE2ECGoFRoaeq8BSZeG8kUiffilC5UEWtciUIun3T4WR2vI8rXMvGtZhK2Yo5zMoQSEUZIWz2HLu3Fss3lGqT8pKWmCbWVVqjAn22Ya0HV11DwucQllm/CrhTCrUH/BIiozPHaIzsc5ZQImUWnj3BZYLslB3pQmw6u9mqorO4XZMzpUrm5UZbWsLRm4a57rAFUXD3tlglJyPu5Uz9R6I/dpuiPwOkLSApAOMkz+A8V7AsAUMtwFb3Wnd72DUAkYd4CLZJRDN0eth3EiUeerdmvn67IFmSM9jMBnRdamYvIrZ5ooyrm2pLczQU1UTA3MCADt6fpoepwKJHbNCtdrr/dqpK2CHarpf9SDNLtXNPz4hKK+r+E5+iwUd/udpNNMQ3d+SfwNQSwMEFAAACAgAAAAAAI86L6y8AAAAmQEAABoAAAB4bC9fcmVscy93b3JrYm9vay54bWwucmVsc7WQSwrCMBBA94J3CLO3qQoiYupGBLdSDxDSaRvaJiETP729KYJacOHG1TC/N4/Z7u5dy67oSVsjYJ6kwNAoW2hTCTjnh9ka2C6bTrYnbGWIQ1RrRyxuGRJQh+A2nJOqsZOUWIcmdkrrOxli6ivupGpkhXyRpivuPxmQjZgs7x3+QrRlqRXurbp0aMIXMKfQt0jAcukrDAKeeRI5wI6FAH8sFsD/dv5mfUM1YngbvEpRbgjzkcxykOGjB2cPUEsDBBQAAAgIAAAAAABja/EoqQAAABkBAAALAAAAX3JlbHMvLnJlbHONz7EKwjAQBuBd8B3C7Tatg4g07SJCV6kPENNrGtrmQhK1vr0ZVRwcf+6/D/6yXuaJ3dEHQ1ZAkeXA0CrqjNUCLu1pswdWV+tVecZJxlQKg3GBpS8bBAwxugPnQQ04y5CRQ5suPflZxhS95k6qUWrk2zzfcf9uQPVhsvbp8B+R+t4oPJK6zWjjD/irAayVXmMUsEz8QX68Eo1ZQoE1nQDfdAXwquQfA6sXUEsDBBQAAAgIAAAAAAAUVUFPBQEAAJkCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbK2Sv07DMBDGdyTewfJaxU4ZEEJJOkA7AkN5AONcEiv+J59b0rfHcQsDKmXpdLLv+77fneVqNRlN9hBQOVvTJSspAStdq2xf0/ftpnigZNXc3lTbgwckSW2xpkOM/pFzlAMYgcx5sKnTuWBETMfQcy/kKHrgd2V5z6WzEWws4pxBm+oZOrHTkayndH0kB9BIydNROLNqKrzXSoqY+nxv21+U4kRgyZk1OCiPiySg/Cxh7vwNOPle01ME1QJ5EyG+CJNUfNL804Xxw7mRXQ45M6XrOiWhdXJnkoWhDyBaHACi0SxXZoSyi8t8jAcNeG16Dv2HPG+eDchzWV55iJ/87zl4/mjNF1BLAQIUABQAAAgIAAAAAAA69A4d5wAAAGYBAAAPAAAAAAAAAAAAAAAAAAAAAAB4bC93b3JrYm9vay54bWxQSwECFAAUAAAICAAAAAAA9kgm4TcBAADGAgAADQAAAAAAAAAAAAAAAAAUAQAAeGwvc3R5bGVzLnhtbFBLAQIUABQAAAgIAAAAAABh+IC4iAEAAGIDAAAYAAAAAAAAAAAAAAAAAHYCAAB4bC93b3Jrc2hlZXRzL3NoZWV0MS54bWxQSwECFAAUAAAICAAAAAAAjzovrLwAAACZAQAAGgAAAAAAAAAAAAAAAAA0BAAAeGwvX3JlbHMvd29ya2Jvb2sueG1sLnJlbHNQSwECFAAUAAAICAAAAAAAY2vxKKkAAAAZAQAACwAAAAAAAAAAAAAAAAAoBQAAX3JlbHMvLnJlbHNQSwECFAAUAAAICAAAAAAAFFVBTwUBAACZAgAAEwAAAAAAAAAAAAAAAAD6BQAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLBQYAAAAABgAGAIABAAAwBwAAAAA=
Well, I don't know the particulars of how you are generating the xml file, but I can tell you how to edit the underlying xml files so that it will work, and then perhaps you can figure out how to use your implementation to change the property that's gunking things up.
First, an xlsx is a set of xml files. I'm sure you know that, but I'm just starting at the beginning. You can change the extension to zip and then extract the files, and then rezip them and change the extension back to xlsx.
So do this:
take the generated xlsx
change the extension to .zip
extract the files
find xl\worksheets\sheet1.xml
open it and find this property: worksheet>sheetViews>sheetView:tabSelected
set it to 0
save the file
go back to the unzipped folder
select all files and send to zip
change the extension on the new zip file to .xlsx
You should now be able to open the newly created xlsx, add a new sheet, and copy freely.
If this works for you, then you have diagnosed the problem, one property set to true when it shouldn't be, and it should be relatively simple for you to modify your export procedure.
I've had this issue multiple times in the past.
The way I solved it was by filling out (populating) a template (file, previously created in Office) with the exported data rather than generating a file from scratch. Office unfortunately does not fully comply with OpenXML, and for more complex exports you might even be unable to open the file.
I would also recommend Beyond Compare (now Scooter Software) for comparing the two files instead of just doing a diff.
I encountered this weird ass and funny error.
I built a file for data ETL. This one takes in various .csv files, combines them and export new .csv files using VBA. The file is originally named as "xxx Modelling ETL.xlsm". It could be opened normally till one day it hangs or crashes while trying to recalculating something (may be the underground query).
After hours of struggling, I opened the file as a copy (under a new name of Copy of ...). Strangely it ran smoothly, no crash or hang. Then I try rename it by remove the "Copy of" part, then the error occurs again.
I want to share this as there could be someone has the same problem, or someone who could shed some light on this black magic thing.
Some solutions:
Rename the file or move it to local drive instead of Onedrive makes thing works normally again.
Open Trust Center, disable Macro with notification, Trusted Locations, and Trusted Documents. Enable them for specific files when open, not for all.
I have a very old VBA file that was created by someone else with limited comments to explain it. The file is a training file that asks for names, and then supplies the file names you can view to train in. Variables are passed around from 5 different subroutines.
RetVal = Shell("C:\Program Files\Microsoft Office\OFFICE11\PPTVIEW.EXE " & ProgFile, 1)
This is the line that opens the PowerPoint 4.0 files from Excel. ProgFile being a passed variable.
My Problem: If I put the files in directory on the C:\ drive (Say C:\Training\Forklift.ppt) the file opens fine and the program does what it is supposed to do.
HOWEVER: Putting those same PPT files on my network Drive (S:\Training\Forklift.ppt) I get three error messages as pop-ups NOT coded into the program (I suspect System errors). (Path names were changed to show as S:\
PowerPoint Viewer Cannot find the File RECORDS
PowerPoint Viewer Cannot find the File Safety
PowerPoint Viewer Cannot find the File Forklift.ppt
RECORDS and Safety are NOT files being used by any of the subroutines. Is it because of the Shell Function to open PowerPoint or some other mystical thing I am overlooking?
I am trying to rewrite the Subroutines and this is part of the unchanged code that is giving me issues.
try surrounding your arg in quotes:
RetVal = Shell("C:\Program Files\Microsoft Office\OFFICE11\PPTVIEW.EXE " & Chr(34) & ProgFile & Chr(34), 1)
My guess is that RECORDS and Safety are both some sort of external files that are linked in your Forklift.ppt presentation. PowerPoint is notorious for breaking presentations when things get moved. If there are any links in the PPT, they will need to be updated to point to the new location on your S: drive.
You can automate changing the links by writing some VBA code for it, but if this is a one-time move, it's probably not worth it - just redo them by hand.
OK, so far I've uninstalled & re installed Office-2010 3 to 4 times, done hours of research for 3 days with no success. I started getting this error either from Vbscript or Excel VBA, performing the same command that has worked for months. I am not sure what I may have changed, I don't recall changing anything that could cause it but I nailed it down to the ReadOnly:=True parameter. I think something may be wrong with the registry... but re-installing should fix it right? It didn't...
Anyways, very simple command that I recorded on Excel 2010. This command WORKS FINE and the file opens:
Sub Macro1()
Workbooks.Open Filename:="C:\temp\file_9928_131101.xlsx"
End Sub
But when I add the ReadOnly:=True parameter, it does NOT WORK:
Sub Macro1()
Workbooks.Open Filename:="C:\temp\file_9928_131101.xlsx", ReadOnly:=True
End Sub
This is the returned error Run-time error '1004' Method 'Open' of object 'Workbooks' failed:
When I click Debug, the error is at the only line of code.
The file is corrupted. Resave it with another name and change the name in the function. Try that it works and after that rename the file as you want to call it.
It worked for me and I had a corrupted file. The read only shouldn't be a problem.
Putting an answer here for others like myself who have this issue and the normal solutions don't work.
Another potential cause of this is corrupted temporary files. I think it may only apply if the file you are trying to open is on a network drive or other remote host.
Anyway, try wiping your temp folder (as in the one you get to if you type %temp% into Windows Explorer) then restarting the computer.
I have had the same issue with an Access file stored in a local OneDrive folder, referencing an Excel file stored in the same local OneDrive folder. The solution was to move all files into a "static" (i.e., not synchronized, not OneDrive) folder.
Thought that this specific case/application might help someone.
I realise this is late but if you want to open & repair a corrupted workbook automatically use:
Set oWB = Workbooks.Open(Filename:="C:\my\file\path.xlsx", CorruptLoad:=XlCorruptLoad.xlRepairFile)
If you are downloading the file from some external source (eg- email), just open the file directly from the email and then save the file. Try opening the file in macro ...hope it works...it worked for me....:)
I had a rogue excel process that was running in the background. When I killed it from the task manager the code worked. I hope this helps.
I was too, going crazy with Workbook.Open function, getting the weird Open fail error for no obvious reason. My code also did some some copy-pasting after Open function, which seemed to trigger it.
Eventually I found out that turning ScreenUpdating OFF seemed to cause this - keeping ScreenUpdating ON, made things click for me (maybe someone finds this helpful in the future). I'm one of those who tends to switch ScreenUpdating off for all code whenever possible.
Application.ScreenUpdating = False
I know I'm answering late on this, but I resolved a similar issue (same error but running excel from a .Net app) by making sure VBA was installed correctly on the target machine.
Control Panel->Programs and Features->Uninstall a Program... find your Office install, Right-click and select "change" ->Add Remove Features->Office Shared Features->Visual Basic for Applications->Run From My Computer
This did it for me.
I've just upgraded to Excel 2010 from 2003. An internal add-in that is heavily used uses the Application.GetSaveAsFilename method to prompt for file names to be used for an export process (exporting information from the current Excel file into an xml configuration file).
In 2003, even if they selected a Read Only file, I didn't get any prompts (which is what I want) leaving it up to me to handle read-only issues (which I do...e.g. I check the file out of source control). However, after upgrading to 2010, I can't select a filename if that file exists and is readonly, forcing me to manually go checkout files first (which is a major downer in terms of proficiency when I'm exporting ~60 files per day).
Does anyone know of any settings/workarounds so that Excel 2010 doesn't prevent (or even prompt hopefully) selecting a filename of a previously existing/readonly file?
Thanks in advance.
Does it help if you use Application.GetOpenFilename instead?
Sub PromptForFilename()
ret = Application.GetOpenFilename
MsgBox ret
End Sub
This doesn't give me any errors for a read-only file.