Access 2010-application using TreeView (MSComctlLib.TreeCtrl.2) shows and populates as expected but suddenly after windows security patches doesn't fire events back to VBA.
Tried with rolling back MSCOMCTL.OCX in /syswow64, but no luck.
Please ping any similar behaviour or hints for fixing the issue.
regards,
The problem appears to be that the registry entries for mscomctl.ocx are broken after the security update. One solution can be found in this KB article. It suggests to run this batch file as administrator:
reg delete hkcr\typelib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.0 /f
if exist %systemroot%\SysWOW64\cscript.exe goto 64
%systemroot%\system32\regsvr32 /u mscomctl.ocx
%systemroot%\system32\regsvr32 mscomctl.ocx
exit
:64
%systemroot%\sysWOW64\regsvr32 /u mscomctl.ocx
%systemroot%\sysWOW64\regsvr32 mscomctl.ocx
exit
I've verified that this works in our environment.
I opened an Access file developed on 32-bit Access 2013 running on Windows 7 32-bit, and had experienced this problem when opening it on 64-bit Access 2013 running on Windows 8 64-bit.
My solution:
Delete the control and add it back again, using the design view on your Access form.
Because the treeview's properties are mostly set programmatically, there should be little to do aside from repositioning it and renaming it.
Related
I've seen tons of posts and sites that address this issue. I've tried every solution I've found but none of them work (I've been trying to figure this out for days now). I have seen many posts with the same exact sounding issue, but either the solution didn't work for me or isn't applicable. With that said...
I have an add-in for Outlook 2007 that is intended to add text to the an email's title and body. It is installed for all users using an .msi file. There is an older version that I deployed last year that works fine. The new version I created has only a few minor input/output changes, nothing major. This new version works perfectly on my development computer in both debug from Visual Studio and from an actual install. However, I can't get it to work on a non-development computer. Here are the details on the program and target computer (development computer and target computer details are the same other than the fact that the target computer doesn't have Visual Studio):
-Using Visual Studio Professional 2013
-Written in Visual Basic
-Target Framework is .NET 4.0
-The add-in is only run once the "send" button on an email is clicked.
-Outlook version is Outlook 2007
-Operating system is Windows 7 Enterprise SP1 32-bit
The problem is that the add-in won't load on the target computer(yes, I know, a bazillion other people have had the same issue). As I said previously, it works fine on my computer in both debug and installed versions. This made me think that the other computer is missing something, so I tried installing the .NET 4.0 framework onto the target computer but it told me that it was already installed. I ran through everything I could think of to get it to work with no avail. Here's how it behaves:
-Installs fine with no errors.
-HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Office/Outlook/Addins/EmailMarkTool/LoadBehavior = 3 after installation.
-VSTO_LOGALERTS = 1
-VSTO_SUPPRESSDISPLAYALERTS = 0
-Outlook opens with no apparent errors.
-LoadBehavior = 0 immediately after Outlook is opened.
-Shows up in the Add-ins under "Inactive Application Add-ins."
-Never shows up under "Disabled Add-ins."
-In the "COM Add-Ins" dialog where I can check which add-ins to use, it shows the correct directory and the Load Behavior is "Unloaded."
-The add-in can be checked. When I click "OK" I don't get any errors. When I go back to the Add-ins, it is unchecked and "Unloaded" again.
-Setting the LoadBehavior to 3 doesn't help because it goes back to 0 as soon as Outlook is started again.
-I inserted a try-catch block into the New() function of the add-in that has a MsgBox pop-up and a Throw.
-I get absolutely no errors anywhere.
-No log file is generated.
I have tried uninstalling, rebuilding, and reinstalling multiple times all with the same result. I just can't figure out why it will work on my development computer but not the target computer. Thanks for reading all of this. I know it's a lot, but I needed to get the details out. Thanks in advance for any input!
[UPDATE]: I just created a brand new minimal add-in just to test if it would work but got the same results.
I found the problem!
The problem may be unique to Outlook 2007. It turns out Microsoft Office 2007 SP1 and SP2 had a bug that prevented it from running VSTO addins. Microsoft released a hotfix that fixes this issue (https://support.microsoft.com/en-us/kb/976477). This was added in to the release of Microsoft Office SP3. However, to activate the fix, a new registry flag must be created but that isn't automatically done with the fix, making the fix useless until you manually activate it (instructions and download here). So...
To enable VSTO addins in Outlook 2007, you have to add a subkey to this registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\Common\General\
and add a DWORD "EnableLocalMachineVSTO" with the value set to 1.
I did this, restarted the computer for good measure, installed my addin for the 23rd time, and it installed and ran perfectly! I'm not sure how previous versions worked, though. It's possible that our system admins removed that subkey in an effort to bolster security at some point.
The loadbehaviour key problem you are experiencing is strange. Whilst I think this is probably not your solution, it could be, so its worth a try.
The target computer will need to have VSTO tools for office runtime installed.
You can download these tools are the following link - https://www.microsoft.com/en-GB/download/details.aspx?id=48217
I'm using Windows 10 and Excel 2016 and I tried to install the Windows Common Controls (SP6) using the file mscomctl.ocx. It ran perfectly under Excel 2013 but not under Excel 2016. I'm looking for the ListView control which does no longer run on the new machine.
I performed the following steps:
Copy the mscomctl.ocx file from a running Windows 10 / Excel 2013 into the folder C:\Windows\SysWow64
Register the file with the cmd prompt regsvr32 C:\Windows\SysWow64\mscomctl.ocx
Referenced the mscomctl.ocx in VBA which then appeared in the list with a checked box
Checked the registry and theres only an entry for Version 2.2. Altough on the running machine I've got 2 entries: (Standard) & PrimaryInteropAssemblyName) where on the not running machine there's only the (Standard) entry.
Step No. 5 would have been adding the control to the Standard controls but None of the common controls does appear in the list.
Does anybody have experienced similar issues? If yes, could you resolve them?
Many thanks
Adrian
This is happening because mscomctl.ocx is a 32 bit only item. It will not work in 64 bit mode.
Addendum: in July 2017 Microsoft published a 64-bit version of mscomctl.ocx, thus since then it is possible to use its controls from Office 64-bit. The 64-bit version of mscomctl.ocx is also part of newer Office versions (like Office16). A good article about using mscomctl.ocx with Office 64-bit is available here.
Instead of coping the file from somewhere, you could always download them from Microsoft
Make sure the "Microsoft Windows Common Controls 6.0 (SP6)" reference does point on the SysWoW64 folder. If not Use the "Browse" button to select it.
Left click on the "Toolbox" -> "Additional Controls", make sure the "Selected Items Only" is not checked, and look for the "Microsoft ... 6.0 (SP6)" controls.
Note that you might experience issues when trying to open the resultant workbook in older versions of Windows and/or Excel.
Solution
I have added a Treeview Active X Control to one of our spreadsheet, using Microsoft Windows Common Controls 6.0 (Service Pack 6), i.e. MSCOMCTL.OCX which lives in C:\Windows\SysWOW64\
KB2881029 (Security Update for Microsoft Office 2010 32-Bit Edition) (MS16-004), pushed out from Microsoft on 2016-01-15 (or thereabouts), installs a new version of MSCOMCTL.OCX (v6.1.98.46) which was "Created" on 2015-12-09, but "Accessed" (i.e. installed on the computer) at the time of the update.
This made the workbook "lose" reference to MSCOMCTL.OCX (quote marks on "lose", because the reference is still ticked but no longer works; the workbook doesn't compile because of "Compile error: Object library feature not supported" or "Automation error").
It seems that the update modifies the following registry key by adding a SubKey 2.0, but leaves it empty, and doesn't register the new MSCOMCTL.OCX:
HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-000F8754DA1}\
Fixing the problem requires three steps:
MSCOMCTL.OCX needs to be unregistered and re-registered from an elevated command prompt, as follows:
C:\Windows\system32>Regsvr32 /u C:\\Windows\SysWOW64\MSCOMCTL.OCX
C:\Windows\system32>Regsvr32 C:\\Windows\SysWOW64\MSCOMCTL.OCX
When registering the new MSCOMCTL.OCX (Version 6.1.98.46) via REGSVR32, a new key is added to the Registry:
KEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-000F8754DA1}\2.2
If there was a SubKey named 2.1 already existing, it enters a reference that 2.2 is now the Key for use. But it doesn't do anything to the empty 2.0 SubKey !
If there is a 2.0 (or 2.1 for that matter) SubKey with nothing in it, any object using that OCX should fail to create because it will use the 2.0 (resp 2.1) Version, it can't and didn't check for 2.2 Version.
Clean up the registry by deleting the wrong or superseded keys 2.0 and 2.1, leaving only the latest and working key 2.2. This can be done from the Registry Editor by selecting HKEY_CLASSES_ROOT, Edit/Find/MSCOMCTRL.OCX.
(Note: this step seems optional as I have checked that doing only step 1 and 3 made the workbook work again. But it feels like the right thing to do)
In the in the Excel workbook VBA project, Microsoft Windows Common Controls 6.0 (Service Pack 6) needs to be unreferenced and re-referenced. Re-referencing is not just a matter of re-ticking the box, you need to use "Browse", and select MSCOMCTL.OCX in C:\Windows\SysWOW64\
(Note, in the browser window, you need to change the file type from "dll" to "OCX" (or "all"))
Daniel Alexander Karr (refer post further below) has kindly shared a script he wrote to do steps 1 and 2 automatically (note that needs to be run as an Administrator).
Thanks Daniel and wmelonman for your help in understanding the problem and finding a solution.
Original Post
Similarly to what is described in this 3 year old post
(VBA Automation Errors due to Office Service Pack 3.0 caused by Forms), a perfectly working workbook of mine stopped working from one day to the next...
In the list of updates carried out last night the following ones are Office Updates:
KB3114563 (Definition Update for Microsoft Office 2010 32-Bit Edition)
KB2881029 (Security Update for Microsoft Office 2010 32-Bit Edition)
KB3114555 (Update for Microsoft Office 2010 32-Bit Edition)
KB3114553 (Security Update for Microsoft Office 2010 32-Bit Edition)
KB3114564 (Security Update for Microsoft Excel 2010 32-Bit Edition)
There were other updates, but general Microsoft Windows updates, not specific to Office, and they hopefully are not relevant here.
My understanding is that the "Automation error" is due to the project not compiling because of the presence of 2 "additional" ActiveX controls on one of my forms that I have referenced from Microsoft Windows Common Controls 6.0 (Service Pack 6), i.e., MSCOMCTL.OCX which lives in C:\Windows\SysWOW64\
Unfortunately un-registering and re-registering MSCOMCTL.OCX as explained in the aforementioned post didn't solve the problem.
I also tried deleting all *.exd, but there weren't any on my C: drive.
Additional info that may be relevant:
The MSCOMCTL.OCX file version is 6.1.98.46, created & last modified 2015-12-09 but accessed at 3.33am yesterday (2016-01-15), i.e. about the same time the updates occurred (3:14am for the latest one).
Once passed the initial "automation error" message, I would get an additional message, "Compile error: Object library feature not supported", highlighting lines of codes associated with the additional controls.
I've verified these were "causing" the problem by creating a blank form an trying to add one on. I got the error message "Could not complete the operation due to error 800a0011".
These additional controls are Microsoft TreeView Control 6.0 (SP6) and Microsoft ImageList Control 6 (SP6).
I could add the Microsoft TreeView Control, Version 5.0 (SP2) and Microsoft ImageList Control, Version 5.0 (SP2) without raising the error (I didn't try making them work though).
Does anyone know of similar mishap with MSCOMCTL.OCX following yesterday's Microsoft updates? That may confirm it could be the source of my problem.
Does anyone know of a fix?
Does anyone know how to report this to Microsoft (if indeed it is the source of the problem)?
And finally, for those interested, there is a way to avoid Microsoft Updates messing up ActiveX controls...not using them! This is what JPK has done for his TreeView.
our Business-ERP-Software Faktura-XP got the same problem since yesterday, we investigated the Problem and created a Patch for it, maybe it will help someone:
http://www.faktura-xp.de/faktura-xp-download/update-und-patch-oeffentlich.html#toggle-id-4
In our Case, the TreeViewControl stopped working, but it will be the same Problem with Automatition. Microsoft updated the MSCOMCTL.OCX to Version 2.2, if the Key
{831FDD16-0C5C-11D2-A9FC-000F8754DA1} has an empty 2.1 or 2.0 Entry the Common Control will stop working.
Solution:
Delete Key 2.0 and 2.1, leave 2.2, unregister the mscomctl.ocx and reregister it.
Our Patch will do exactly this, nothing more, nothing less, but as simple as possible for our customers, just click Next and Close.
Edited for more information:
HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-000F8754DA1}\2.2
is freshly created when register the new MSCOMCTL.OCX (Version 6.1.98.46) via REGSVR32
When there is a SubKey named 2.1 it enters a reference that 2.2 is now the Key for use.
If there is a 2.1 SubKey with nothing in it, your Object will fail to create because it will use the 2.1 Version, can't and didn't check for 2.2 Version.
Delete this Key if neccessary and youre good to go.
Further Testings shows that 2.0 SubKey is obsolete and could cause Problems.
Mostly Systems with Microsoft Windows 7 had this Problem. For our Software, no-one with Windows 8.1 or Windows 10 called a Problem after the current Update.
Similiar problem here: Ancient Access 97 app on ancient XP (not for long anymore, sigh of relief) quits saying "Error 91: Object variable or With block variable not set". Examination showed it happens when the progress bar control which resides in Mscomctl.ocx is adressed.
I found that KB2881029 (MS16-004) is the culprit. It installs the new version of MSCOMCTL.OCX. On machines w/o this update the Access app works fine. But it is not suited for removal, at least this is what our WSUS told me when I was going for it. Anyway we wouldn't want to live w/o a security update.
Having read the answer concerning HKCR\TypeLib{831FDD16... I tried deleting the at that time still populated \2.0 subkey prior to installing the update only to find out that even with a non existing \2.0 subkey the update does create the empty one on installation. Well done, Microsoft...!
Thanks all for your contributions,
I have found that de-referencing and re-referencing the Microsoft Windows Common Controls 6.0 (Service Pack 6) in the Excel VBA project would finally make it work.
!!!...BUT...!!!
Simply un-ticking / re-ticking the tick box would be too simple ! For re-referencing it, you need to use "browse", and select MSCOMCTL.OCX in c:\Windows\SysWOW64\
(note, in the browser window, you need to change the file type from "dll" to "OCX" (or "all"))
I have tried simply doing this on a machine where I hadn't run Daniel Alexander's Patch (to un-register and re-register MSCOMCTL.OCX, and remove the old empty 2.0 key from the register), and it didn't work, so I expect the above steps are required. I will try to thoroughly test which steps are necessary and edit this answer to spell out the whole procedure, step by step, but for the time being running Daniel Alexander's patch (AS ADMINISTRATOR !) and re-referencing Microsoft Windows Common Controls 6.0 (Service Pack 6) in the Excel VBA project seem to work.
The problem has been described in detail here:
"Error messages or Access crashes after you install security update MS16-004"
MS: Article ID: 3139567
(Last Review: 02/16/2016 19:15:00 - Revision: 3.0)
https://support.microsoft.com/en-us/kb/3139567
I have written a user interface in Visual Basic that sends commands to AutoDesk Inventor to create 3D CAD assemblies. Towards the end of my program, the CAD file is saved and a SaveDialog box comes up. It was working perfectly fine for a while, but now there is an error. Here is the relevant code segment:
SaveDialog.Filter = "Inventor Part | *.ipt|Step File | *.stp"
SaveDialog.DefaultExt = "ipt"
SaveDialog.ValidateNames = True
SaveDialog.ShowDialog()
On the last line shown, I get a run-time error as follows:
"The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is
missing from your computer. Try reinstalling the program to fix this
problem."
After closing this error message, the SaveDialog box comes up anyway and works perfectly fine. Of course, on the compiled version the error box never actually shows up and the program simply hangs up indefinitely.
I have search for solutions to this problem for two days. I used Dependency Walker and found a list of other dlls that are reportedly missing, most of them under the MSHTML.DLL
I figure there is probably something that is not referenced correctly in my program, but I'm not sure where to look. Thanks for any help!
The problem is that the KB2999226 (Universal CRT) which is part of the Visual C++ Redistributable failed to install. Is your automatic updates turned OFF?
Solution
Install Windows Updates:
Go to Start - Control Panel - Windows Update
and click on Check for updates. Install all available updates. After the updates are installed, restart your computer. After the restart repeat the steps above again until no more updates are available.
Download the Visual C++ Redistributable:
For Windows 64-bit
http://download.microsoft.com/download/9/3/F/93FCF1E7-E6A4-478B-96E7-D4B285925B00/vc_redist.x64.exe
For Windows 32-bit
http://download.microsoft.com/download/9/3/F/93FCF1E7-E6A4-478B-96E7-D4B285925B00/vc_redist.x86.exe
Run the vcredist_x64.exe (64-bit) or vcredist_x86.exe (32-bit) and select Uninstall. Run the .exe again and select Install
I'm using the Crystal Report 10 viewer ActiveX control in an Access App I've written. Works great in Office 2003 on 32bit versions of Windows. The problem arrises when I try to run the program in 64 bit Windows (with 32bit Office). I get the following error:
Run-time error '429': ActiveX component can't create object
I get this error on the following line of my VBA code.
Set rdApp = CreateObject("Crystalruntime.application.10")
How can I get this to work in 64bit?
I don't have any specific experience with Crystal Report, but I do have some experience with installing components on a 64-bit Windows environment that were intended for 32-bit Windows, so here are some general suggestions of things to try:
Before installing, try loosening the security privileges - I have Windows Server 2008; on this OS, they're under Start | Administrative Tools | Local Security Policy. Many old installers are thwarted by these controls. You'll want to return them to their defaults after the install.
Make sure that you run the installer with admin privileges (right-click; run as Administrator).
Examine the installation log for Crystal Report - it may indicate a failure registering a component. In one instance, I was able to get the installation working by running the command to register the failed component manually, on an administrator-privileged command line (the command was in the log).
If acceptable, try to create a Windows Virtual Machine running a virtual Windows XP, and try the installations there (this might be a bit tedious, due to your need for MS Office).
Take a look at VMWare's ThinApp - this is intended for packaging applications for administrators, but this was the solution we ended up using to shield one of our 32-bit apps from Windows 64-bit perils
Hope this helps; we struggled for awhile trying different things to get our legacy apps working on a 64-bit environment.