Apologies if this is in the wrong site.
A while ago I placed a password onto my Excel document, and I have never looked at it again until recently and discovered that I can no longer remember the password. I have tried the following:
Entering VB code - However in order to be able to enter the VB code you must enter your password. This proved no such luck.
Zipping the file, and then un-zipping to gain access to the .xml file to edit the protection, this file, seemed just corrupt and contained an error within the xml / the xml did not show up when opening it in a XML editor.
I'm completely at a loss as to what I can actually do and this document is of importance and I need to edit it. Does anyone have any suggestions to what I can try in order to solve this?
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'm encountering an issue trying to get some macros and VBA scripts working on a new coworker's computer. I've been using the same code for years on my machine and several others without issue, but when my new analyst tries to run it, it throws an error stating it couldn't save the file. He can manually save the file without issue, but running the script throws the error. The really weird part is that it lists the file path, but replaces the filename with a seemingly random hex byte.
On another file, if he opens it, closes with or without saving, then I open the file and try to save it using a macro, it fails saying "cannot access file...". If I copy and paste the file, open and run the macro again, it saves over the offending file no problem.
We've checked permissions and settings and haven't found anything that was different between the two systems. We're both on VMs. His hardware allowance is less than mine but otherwise they're both IT-managed and identical. I'm at my wits' end... Any advice on what may be the source of my grief would be helpful, even if not a solution.
A couple of things I'd check before trying to step through debugger mode.
Coworker does not have write access to the directory (I think you said you checked already)
The new users' Trust Center Settings are not correct
File > Options > Trust Center > Trust Center Settings... > Macro Settings > Ensure the box is checked to trust the VBA model and that macros are not disabled
The new user does not have the same libraries referenced.
Alt + F11 > Tools > References... > Check if coworkers' libs match yours
Is he using a new/different version of Excel that you? A lot of older code got bojangled when Office 365 hit the scene.
After checking settings, I would ask the following:
What error is thrown when coworker attempts to run the macro?
When does the error get thrown? It could be that you have code that is attempting to edit the file (or has another file stuck in an edit) at the same time you're trying to save it.
I would see why the file name is getting corrupted. It sounds like coworkers' machine is looking to a bit of memory or memory address that is somehow getting forgotten. Like the code is referencing a variable that is out of scope.
User Access Control has been enabled on his VM that is somehow preventing him from saving the file correctly.
Your code does not properly Quit the Excel application, so its still running in the background on coworkers' machine. Have them open/close without saving a file and check Task Manager to see if Excel is still up to confirm
I'm currently working on my data using Ms.Excel.
But suddenly the file that I'm working in was broken. when I tried to open it again I get error where it contain "ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ" (See Picture).
Screenshoot Corrupted Excel File
The data was not really big, it's only arround 130KB. Besides, Autorecovery Mode was Turned On every 10 minutes. But I don't know How To use it.
I tried to solve the problem many times using below method:
First, I tried to check the "Ignore .... " in Excel Option.
Second, I tried Open and Repair the file, but still can't open it.
Third, I tried to use a third party, Using 2 Software (Stellar Phoenix Excel Repair And Recovery Tools For Excel). but Both not Working.
So I wonder if anyone can help me to get my data back? is there any way to recover the file? or is there a way to get the data within the file?
Thank you for all the suggestion you gave me, From the last comment I tried to get and extract the data using Programmer editor and using VBA, but both not give a good result, basically when you tried to extract the data when the file is corrupted it only get a unique character.
So here is my solution, since i'm using windows, I tried to Reinstall my Ms.Office and recover my Excel file on mac, and boom the magic worked.
Once again, thanks for your help.
Is there a possibilty to prevent a user from sending an excel document while it is still opened?
I had to make my document clear certain cells (containing personal data/personally identifiable information). I succesfully did this by using a function that generates a prompt before saving and only saves (and clears the respective fields) when accepting and doesnt do anything when canceling).
However, users can still send the opened document that contains the critical data.
I know it's a stretch, but is there a possibility to prevent this?
Like, with some sort of checksum/encryption shenanigans that corrupts the document while opened, thus rendering a sent copy in this state useless/not accessible/broken. The document would only be "fixed" again when saving (thus erasing the critical data too).
I can only imagine something like this, because forbidding other programs to read an opened excel document seems crazy.
Any help is greatly appreciated. Thanks in advance!
And hello to everyone here! (first post) This place is a lifesaver.
EDIT: For clarification:
1. Users get the excel document.
2. They enter personal data of staff/applicants etc. into it and my document does fancy stuff.
3. An output is generated which needs to go into some other tool.
4. The excel document's purpose is fulfilled and it must clean itself from filthy personal data.
This is achieved as described before. Saving etc. is all sorted out.
The problem I have been told to deal with, is to make it impossible to send the document while it still contains personal data. Closing wipes it, but while open, it still does contain personal data and can be interacted with Outlook etc.
Is there a way to prevent this kind of interaction with the document while still open? Or make the document corrupt while open, so copying it in this state won't transmit any personal data?
and welcome.
Your question is a bit of a strange one and I am not sure what would be the perfect way, but let me try answer and give you some suggestions:
A: You could work with a codeword in a specified cell. When you save a file it will put the word in that cell. When the word is not there.....well, let's say you can create some macro in Workbook.Open event that will delete all cellvalues and saves the file on its current location. Obviously put password on vba coding!
B: A more solid way in my opinion is to work on the file in your personal workspace if possible and upon saving the file create a copy to the shared folder through vba.
Good luck with it.
A: Manipulating the checksum/temp encryption would be quite risky since if your code crashes or is halted and closed the file is either corrupt or encrypted for you aswell, so information might be lost.
B: You could make the file copy to a temp while editing.
C: You can maybe block the save/autosave function of excel so that your editing won't get saved half-way in. (Not really a good solution, but a solution, likely quite easy).
EDIT:
For option C:
Insert this to workbook, it runs as it's named, before save.
Private Sub Workbook_BeforeSave(ByVal SaveAsUI As Boolean, Cancel As Boolean)
//INSERT INSTRUCTION TO REMOVE PERSONAL DATA
End Sub
With this, data is removed before file is saved, so any saved state should be clean. Macro-deactivated workbooks however, cannot solve this problem, so you should maybe also add an event at workbook open that unlocks the sheets via VBA to avoid that flaw.
We have a file that gets imported by a macro to extend Excel's macros functionality. This file has an extension .dll. The person who originally made this purposely changed the extension to dll to make it a bit less easy for users to just open it. All was well, but now the latest excel 2016 update gives an error "file format and extension mismatch".
which is correct. Now, in my opinion, I have 2 options.
change the extension to what it originally was (which I don't know).
bypass the extension/file format mismatch (which I don't know how to do and might pose a security risk).
I tried the following extensions: xla,xlam,xlsx,xlsb,xlm,xls,xll. but still get the same message.
Does anyone have a clue on how I can find out what the original file extension was?
I am not sure but the file might have been created in excel 2000 or 2007.
I found out that the issue is not with extension or file format but the problem was caused by AV/bit Defender which saw the file as a zip file started scanning inside and removed a single file inside thus causing excel to no longer recognise it as a valid file.
I noticed some weird behaviour as soon as I restored quite some files from backup, AV defender started using 95% cpu. after that I went into the logs and noticed defender thinks it is a trojan.
Thanks all for your input!