Windows 10: OLE seems broken for Excel

Posting this in Windows because I don't think it's an Office problem... I think it's an OLE problem. I can't seem to correctly embed an excel object into Word or PowerPoint. This broke a couple of days ago - it just shows up as an Icon instead of a spreadsheet like it used to. When I edit documents that I previously embedded spreadsheets into Word describes it as an "Unknown Object" and won't allow me to edit or open it, only gives me the option to Convert it (to an Unknown Object!). Anyway, it seems Windows forgot what an Excel Object is...

:)

 

Excel crashes while creating workbooks using OLE Automation when Microsoft Print to PDF is the default printer

Hello Graham,

To better assist you with crashing Excel when using OLE Automation concern, we would suggest you to re-post this query to
MSDN forums.

Regards.

 

how do i get rid of OLE Initialzation failed make sure that OLE libraries are the current version

Hi,



Thank you for writing to Microsoft community forums.



Object Linking and Embedding (OLE) is a proprietary technology developed by Microsoft that allows embedding and linking to documents and other objects. Before an application can use OLE system services, it must initialize the OLE system DLLs and verify
that the DLLs are the correct version. Make sure that the service Windows Modules Installer is running. To check if the service is running, please follow the steps mentioned below:

1. Open Run dialog (press Windows key + R).
   
2. Then type: Services.msc and click on
   Okay.
   
3. Then look for the service named Windows Modules Installer.
   
   

For more information, you can refer to: OLE Initialization. If you need
any further assistance, please write back with the following information:

1. When do you get the above error?
   
2. Is the issue specific to any application?
   
3. Which version of Windows 10 is installed on your device?
   
4. Are you aware of any recent changes that were made on your computer?
   

Regards,

 

Export All Administrative Events to Excel


To analyze events, from the Windows Event Viewer, there is a simple way to export all Administrative Events to Excel, with PowerShell.

Exporting all Administrative Events to Excel is a simple two Step process, as described here:

Step 1 - Create the Administrative Events View .xml file

1. Open Eventviewer (%windir%\system32\eventvwr.msc)
2. Navigate to: Event Viewer (Local) > Custom Views > Administrative Events
3. In the “Actions” pane select “Filter Current Custom View”.
4. Select the the XML tab.
5. Press Ctrl+A to select all the XML code of the Custom View.
6. Open a notepad, paste the selected code and save the file to your Desktop as AdmEvtView.xml

Step 2 - Create the csv file with the events

1. Download the ExportEvtCSV.zip file, which contains the script ExportEvtCSV.ps1 and unzip it, on your Desktop.
   It's not a fancy script, just basic PowerShell commands to create a csv file on the Desktop.
2. In Windows Search, type “ISE” (without the quotes) to open “Windows PowerShell ISE” and Run as administrator
   
3. To allow running the script, change the ExecutionPolicy, for this session. To do that, in the Console pane type:
   Code:
   
   Code:

   Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -force

4. In the Windows PowerShell ISE, open and run the script: ExportEvtCSV.ps1
   The script will create a csv file with a name YYYYMMDD.HHMM.csv on the Desktop
5. When done, open the newly created .csv file, format the columns as needed and optionally save it as .xlsx, if you wish.

That’s it! You now have all the Administrative Events in Excel for filtering and further analysis.

Now to the more technical hard stuff... *Confused

There is a reason for running the script from within PowerShell ISE!

It would be great if everything was also working perfectly, when running the script from an elevated PowerShell too.

We can run it from an elevated PowerShell, which means that you just follow the Step 1, as above but for the Step 2 instead of the ISE you run the script from an elevated PowerShell.

The problem is that it will work only for anybody who has en-US format for the dates. Everyone else, who has another format (i.e. en-GB, fr-FR, el-GR etc.), the dates are not translated properly by Excel (although the script uses the –UseCulture switch) and remain as text in the en-US format.

I'm not sure if this a bug of the "export-csv" cmdlet, but although it runs the way it supposed to from within the ISE, from PowerShell there is a problem with the dates format.
As I haven’t found a way to overcome this obstacle, any suggestion from the PowerShell gurus of the forum (like my good friend Shawn @Brink, for instance), is welcome.