none
DLL won't register

    Question

  • I have an app dll that refuses to register in Windows8. It worked fine in Windows7. Some users report it works OK on there system but most report the same error

    When we run regsvr32 to register the dll, it generates an error that says it was loaded ok but the call to DLLRegisterServer failed with error code 0x80004005.

    Research on this error says it corrected by running with elevated rights. We run the process as an Admin. We have tried opening CMD prompt as an Admin, turned off Windows Defender, disabled Windows Firewall and also tried doing it in Safe Mode. Every attempt always returns the same error code.

    I have tried multiple searches but all say just to run in an elevated mode. We do but it still fails.  All searches indicate the error is an indicator of a security issue.

    Does anyone have any ideas what may be causing this and how to correct it - Can you help me find the forum that would be appropriate for this info.

    The app ran fine in Win7, and survived an in-place upgrade to Win8. It seems to appear with new OS installs or when the registry is cleaned of any reference to the app and then an install is attempted.  The app uses five other DLL's, all by the same developer and they load fine.?

    Paul

    • Moved by Dave PatrickMVP Saturday, December 29, 2012 2:39 PM (From:Where is the Forum For…?)
    Saturday, December 29, 2012 3:27 AM

Answers

  • I posted comments to the developer who responded:

    Yes, the OsaSync code is old, written in Visual Basic 6. Nevertheless VB6 applications and also vb6 add-ins should still be able to run on ALL windows versions, including Windows 8. Most VB6 runtime files are even part of the OS since Windows Vista!

    Also, osasync still installs and runs fine on many systems, including on Windows 8. That’s the weird thing, the osasyncpro.dll won’t register on your system both on almost all others it does. So it can’t be a structural problem of the compiled dll or the installer I used (which I recently upgraded to the lasts version hoping that would solve these registration problems…).

    To summarize your problem: on most systems this dll registers fine and on some it triggers this error which points to a security issue.

    I am remember correctly you installed on a clean windows installation, right? Could you have applied some extra security that restricts writing to the windows registry? Or could some other app like an anti-virus app interfere? I am completely in the dark here.

    I have tried disabling Microsoft security, firewall and UAC when attempting to register the DLL. I tried running the commands using the suggested PsExec and still the same error in the one DLL.

    The developer admits to having seen the error before but only in limited cases. There are multiple instances of Win8/Outlook2013/OsaSync running successfully. There is just something peculiar to a handfull of machines that causes this error. I know it runs, it did for me when I upgraded from Win7 to Win8 and also when I went from Outlook2010 to Outlook2013. The error occurs when I scrubbed the registry to clean all remnants of the program. I then did a complete clean OS and Office install to try and correct it and the problem persists.

    Don't know if this one is solveable or not. The developer says he's done with future versions of the program and is only doing bugfixes, such as this. But he also can't find a solution or a cause to help me.

    Paul

    Monday, December 31, 2012 4:24 PM

All replies

  • I have an app dll that refuses to register in Windows8. It worked fine in Windows7. Some users report it works OK on there system but most report the same error

    When we run regsvr32 to register the dll, it generates an error that says it was loaded ok but the call to DLLRegisterServer failed with error code 0x80004005.

    Research on this error says it corrected by running with elevated rights. We run the process as an Admin. We have tried opening CMD prompt as an Admin, turned off Windows Defender, disabled Windows Firewall and also tried doing it in Safe Mode. Every attempt always returns the same error code.

    I have tried multiple searches but all say just to run in an elevated mode. We do but it still fails.  All searches indicate the error is an indicator of a security issue.

    Does anyone have any ideas what may be causing this and how to correct it - Can you help me find the forum that would be appropriate for this info.

    The app ran fine in Win7, and survived an in-place upgrade to Win8. It seems to appear with new OS installs or when the registry is cleaned of any reference to the app and then an install is attempted.  The app uses five other DLL's, all by the same developer and they load fine.?

    Paul


    File names and the program concerned would probably be a help...
    Saturday, December 29, 2012 3:59 PM
  • Sorry, since they weren't common apps or dll's, I didn't think it would matter.  The app is called OsaSync. It is a program that will sync two or more Outlook PST files. The dll in question is named OsaSyncPro.dll.

    The app was developed by Vaita in Europe. I have been in contact with the developer and he has thrown his hands up. He has seen the issue before but generally says running in elevated command will clear the issue.

    The app was written in VB6 and is probably nearing its end of life. VB6, I am told, will not convert to 64bit, which eventually, will be an issue.

    If the app didn't work at all on Win8, I would understand. But it did operated on a Win7/Win8 upgraded system just fine. It is only after I did a new OS re-install that the issue appeared. And I see the same issue on both my laptop and my desktop. Both running Win8Pro, 64bit with Outlook2013, 32bit.  Same settings as when it was the OS Upgrade.

    This is getting way beyond my pay-grade. I admit to knowing just enough about this to be dangerous. But was hopeful I could find a way to register the DLL and get the program to run once again. Another MVP suggested a work-around

    "There is dirty method, namely running registeriing as script in Scheduled Task (Priviledged and with SYSTEM account).

    But I haven't deciphered his terminology yet to understand exactly the process he is referring to.

    Paul

    Saturday, December 29, 2012 5:51 PM
  • This is getting way beyond my pay-grade. I admit to knowing just enough about this to be dangerous. But was hopeful I could find a way to register the DLL and get the program to run once again. Another MVP suggested a work-around

    "There is dirty method, namely running registeriing as script in Scheduled Task (Priviledged and with SYSTEM account).

    But I haven't deciphered his terminology yet to understand exactly the process he is referring to.

    another method (slightly less complicated) would be to use the MS/Sysinternals psexec tool.

    download psexec to the machine: http://technet.microsoft.com/en-au/sysinternals/bb897553

    open an elevated (runasadmin) CMD console [you should be prompted for UAC consent]
    within the elevated console, execute: psexec -i -s CMD [you should be prompted for UAC consent]
    [this will open another CMD console window, running as LocalSystem instead of the logged in user]
    within the LocalSystem CMD console window, attempt your dll registration


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)


    • Edited by DonPick Sunday, December 30, 2012 12:30 AM
    Sunday, December 30, 2012 12:28 AM
  • Don

    Appreciate your response and tip. I tried running psexec but it resulted the exact same results. The other dll's registered just fine, the main one OsaSyncPro.dll returned the same 0x80004005 error.

    Paul

    Sunday, December 30, 2012 9:44 PM
  • ok, I've had a quick look into the downloadable installer for this product, and it seems that it has been written in an older version of visual studio.

    possibly, the DLLregister function is failing if some other pre-requisite file is missing, and the file is not missing when an OS upgrade from W7->W8 is done?

    the developer needs to check, what runtimes are needed (and may be missing on W8 compared to W7).
    Or, some extended debugging on W8 (perhaps using process monitor or some other debugger) may be needed.

    I note that the developer's website mentioned this product works on Win95->Win7.
    It seems that Win8 is not yet listed as supported. Also, if this product functions on platforms as old as Win95, then the traces of VB6 I found in the fileset are likely to confirm the vintage of this product. An awful lot of things have changed since those days, and maybe there are some additional steps/files needed to get this application to work on a clean install.


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Monday, December 31, 2012 12:40 AM
  • Don

    Appreciate your taking a look at this. I'll forward your comments to the developer

    Thanks

    Paul

    Monday, December 31, 2012 1:30 AM
  • Just to be sure ...

    Remember, if your using some cmd-file (i.e. cmd) to register the DLL - then run as administrator by right clicking on the command will run it from \Windows\System32. So in that case the command needs to be programmed to know the location of the dll to register.

    However, if you tested with opening a command prompt as administrator, changing directory to the cmd and then running it ... then you did the run as administrator right ... if this is a command file.

    Another option could be that dll has been programmed with an error that happens to show off now - where as the other dll's without such an error does not have a problem. Or it may call something that has been completely deprecated today (try to research that dll's functional dependencies)? I.e. you kind of indicate you're not the programmer mentioning the programmer in almost past tence ... an old program.


    Monday, December 31, 2012 4:58 AM
  • I posted comments to the developer who responded:

    Yes, the OsaSync code is old, written in Visual Basic 6. Nevertheless VB6 applications and also vb6 add-ins should still be able to run on ALL windows versions, including Windows 8. Most VB6 runtime files are even part of the OS since Windows Vista!

    Also, osasync still installs and runs fine on many systems, including on Windows 8. That’s the weird thing, the osasyncpro.dll won’t register on your system both on almost all others it does. So it can’t be a structural problem of the compiled dll or the installer I used (which I recently upgraded to the lasts version hoping that would solve these registration problems…).

    To summarize your problem: on most systems this dll registers fine and on some it triggers this error which points to a security issue.

    I am remember correctly you installed on a clean windows installation, right? Could you have applied some extra security that restricts writing to the windows registry? Or could some other app like an anti-virus app interfere? I am completely in the dark here.

    I have tried disabling Microsoft security, firewall and UAC when attempting to register the DLL. I tried running the commands using the suggested PsExec and still the same error in the one DLL.

    The developer admits to having seen the error before but only in limited cases. There are multiple instances of Win8/Outlook2013/OsaSync running successfully. There is just something peculiar to a handfull of machines that causes this error. I know it runs, it did for me when I upgraded from Win7 to Win8 and also when I went from Outlook2010 to Outlook2013. The error occurs when I scrubbed the registry to clean all remnants of the program. I then did a complete clean OS and Office install to try and correct it and the problem persists.

    Don't know if this one is solveable or not. The developer says he's done with future versions of the program and is only doing bugfixes, such as this. But he also can't find a solution or a cause to help me.

    Paul

    Monday, December 31, 2012 4:24 PM
  • Don't know if this one is solveable or not.

    A good way to diagnose problems with regsvr32.exe  is to use  DependencyWalker  for its  Profiler  feature.   That way you may find out that the problem .dll is not the one that you are trying to register.   For good measure run ProcMon at the same time.   Or perhaps just run ProcMon to trace the cmd window invocation and see what the return code implies.

     
    Good luck

     
    Robert Aldwinckle
    ---

    Monday, December 31, 2012 10:04 PM
  • I am having the same problem with OsaSync and came here googling for a solution (since the program author didn't respond at all for more than a week now).

    I tried the psexec method described here (thanks for explaining!).

    I first ran OsaSyncPROsetup.exe (v8.0.4) in that command console but, alas, got the very same error. Then, in that same cmd window (opened by psexec) I re-ran it but tried the "ignore" option and subsequently, still in that cmd window, manually ran the "registerfiles.bat" that one can find in the created "C:\Program Files (x86)\OsaSync" folder (for both commands I first cd-ed into the respective directory). To my surprise and unlike before (when I had tried executing this first under my own account or then again using "run as admin") this worked without any error. So at first I had high hopes that this OsaSync DLL would now be registered and work, but, alas, not so!

    The OsaSync plugin is still not showing up in the list of Outlook's plugins and so there is still no syncing between my two machines! :-(

    So, either this DLL must be registered as the end-user under which Outlook (and hence OsaSync) are later running or something else is still broken or missing...

    • Edited by mmo17 Tuesday, February 05, 2013 7:43 AM
    Tuesday, February 05, 2013 7:39 AM
  • mmo17

    Sad to hear you are having the same issues. I corresponded with Ronald, the program author numerous times when this issue came up. He is on another assignment and admitted he can not provide the full support to OsaSync as he once did. I read between the lines that the program is nearing its "end of life". He told me it was written in VB6 and when he tried to port it to a different language so it could follow the path of the Microsoft Operating Systems, he said the project was too daunting and not cost justified. 

    He is running Windows 8 on his system and it is working on his. It was working on mine till I did a fresh reinstall of the OS and then the program. There is apparently a bug in how the program writes the registry. I am guessing if you had an upgraded system, the necessary settings get carried over. But if you do a fresh reinstall, it is blocked.

    He reported he is getting more and more reports of the issue and doesn't have an answer nor the time to troubleshoot it.

    I hated to do it, but I have had to move to a different program. I am presently using SynchPST to accomplish the same thing. That program is working with Windows 8 and Outlook 2013, and will run in 64 bit if required. A few minor bugs but it is working and I am able to sync my files.

    I wish OsaSync could be cleaned but I suspect it is done. I thought I would read thru one of my achived registries to find the missing line of code but decided it just wasn't worth all the effort and no one could tell me if that would work or not. I asked Ronald about this and he didn't hold much promise so I dropped that idea.

    Paul


    Tuesday, February 05, 2013 2:51 PM
  • Sad to hear that. I had tested SyncPST before I decided to go with OsaSync, but given your above comments I guess I'll have to bite the bullet.

    Re. this happening only on fresh installs: neither is true in my case: my system was first in-place upgraded from Win7 to Win8 (after which Outlook and OsaSync still worked fine).

    About 10 days ago I did an in-place upgrade from Outlook 2010 to 2013 (staying with the 32-bit version instead of the 64-bit version to exactly avoid (supposedly...) such issues with plugins. Only after that upgrade this OsaSync issue hit, i.e. OsaSync was at first still listed among the installed plugins but it was ticked off and every attempt to check it would be ignored. So I uninstalled the old version (7.0.x) and re-installed 8.0.4 which then showed this bug with the registration of the DLL.

    So, it really seems to be some tiny, stupid issue, but - as often in IT - with annoying consequences. What a pity...

    Cheers and thanks,

    Michael

    Tuesday, February 05, 2013 8:42 PM
  • Hi guys, I am Ronald, the author of OsaSync. I'll specify some details about the OsaSyncPro.dll file hoping that someone can point to a solution.

    The OsaSyncPro.dll file is a created as VB6 Addin project and compiled as a single threaded ActiveX dll. All compilation options are default. This addin has a reference to an ActiveX standard exe component 'osasync.exe'. Almost all OsaSync's functionality is offloaded to the osasync.exe component. The OsaSyncPro.dll creates the OsaSync menu and listens to some outlook events. There's also a reference to OsaLang.dll, an activeX dll with language strings, a ref to a progress bar ocx and a reference to the Redemption dll. All other references are references to required VB and Office (2007) runtimes. Here's a listing of all references from the .vbp file:

    Type=OleDll
    Reference=*\G{00020430-0000-0000-C000-000000000046}#2.0#0#..\..\..\..\..\..\..\Windows\SysWOW64\stdole2.tlb#OLE Automation
    Reference=*\G{AC0714F2-3D04-11D1-AE7D-00A0C90F26F4}#1.0#0#..\..\..\..\..\..\..\Program Files (x86)\Common Files\DESIGNER\MSADDNDR.DLL#Add-In Designer/Instance Control Library
    Reference=*\G{EF404E00-EDA6-101A-8DAF-00DD010F7EBB}#5.3#0#..\..\..\..\..\..\..\Program Files (x86)\Microsoft Visual Studio\VB98\VB6EXT.OLB#Microsoft Visual Basic 6.0 Extensibility
    Reference=*\G{00062FFF-0000-0000-C000-000000000046}#9.0#0#..\..\..\..\..\..\..\Program Files (x86)\Microsoft Office\Office14\MSOUTL.OLB#Microsoft Outlook 9.0 Object Library
    Reference=*\G{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}#2.1#0#..\..\..\..\..\..\..\Program Files (x86)\Common Files\Microsoft Shared\OFFICE14\MSO.DLL#Microsoft Office 9.0 Object Library
    Reference=*\G{2D5E2D34-BED5-4B9F-9793-A31E26E6806E}#4.6#0#..\..\..\..\..\..\..\Program Files (x86)\OsaSync\vaMoreUtils.dll#Redemption Outlook and MAPI COM Library
    Reference=*\G{1C270A30-8BBB-462B-9294-8BFC5CD38DE2}#1.0#0#..\..\..\..\..\..\..\Program Files (x86)\OsaSync\OsaLang.dll#OsaSync languages
    Reference=*\G{3EE066A7-ABE9-42DD-B6B0-5886C9EDAD6D}#2.0#0#..\..\..\..\Outlook_AddIn\test_version\OsaSync.exe#OsaSync activex server
    Object={05CECBEA-0099-11D2-8E21-ACB204C10000}#3.0#0; cProgBar.ocx

    The osasync installation file is created with Inno Setup (5.5.2). This line installs the osasyncpro.dll:

    [Files]
    Source: "C:\OsaCode\OsaSyncPro.dll"; DestDir: "{app}"; flags: regserver ignoreversion restartreplace

    No custom registry keys are created during installation and registration. During registration the a standard Addin key is created:  HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\OsaSyncPro.Connect. Creation of a key in \Outlook\Addins is standard for an Outlook AddIn.

    As explained by Paul already, the registration problem only arises on SOME installations, most installations are fine. All customers reporting this problem run Office 2013. Here's the system setup of these customers:

    - Win7 Ultimate x64 and MS Office 2013
    - MS Outlook 2013 (32-bit version on Window 8/x64)
    - Win8 (Vers. 6.2.9200, 64 bit), Office 2013 (Vers. 15.0.4420.1017, 32 bit)
    - Win8 machine with Office 2013. On outlook 2010 no problem!

    One customer reports no problem with Outlook 2010, only after installation of Outlook 2013 OsaSyncPro.dll won't register anymore.

    Hope some Microsoft guru can shed a light on this issue...

    Thanks, Ronald

    Wednesday, February 13, 2013 11:28 AM
  • As explained by Paul already, the registration problem only arises on SOME installations, most installations are fine. All customers reporting this problem run Office 2013.

    Has anybody tried using DependencyWalker Profiler or ProcMon to get some details yet?

     
    ---

    Wednesday, February 13, 2013 8:13 PM
  • I don't know whether that helps anyone but I did searches in my registry for each of the keys listed.

    All were found except the following two:

    Reference=*\G{EF404E00-EDA6-101A-8DAF-00DD010F7EBB}#5.3#0#..\..\..\..\..\..\..\Program Files (x86)\Microsoft Visual Studio\VB98\VB6EXT.OLB#Microsoft Visual Basic 6.0 Extensibility

    and

    Object={05CECBEA-0099-11D2-8E21-ACB204C10000}#3.0#0; cProgBar.ocx

    where missing.

    Does that maybe ring a bell for anybody? I guess the first is some library. Can one install this VB 6.0 Extensibility library from somewhere?

    Michael


    • Edited by mmo17 Wednesday, February 13, 2013 11:04 PM
    Wednesday, February 13, 2013 11:03 PM
  • More input - I attempted these things with no success

    1. Tried Win7 version of the VB6 dll from Ronald. No change. dll's still won't register
    2. Tried changing ownerships but no change
    3. Tried the install using ProcMon but didn't get anything out of it. But this also is about 2 levels above my paygrade so I may have missed something.
    4. Tried changing ownership using SubInACL (http://www.microsoft.com/en-us/download/details.aspx?id=23510) and then reinstalling but no changes

    As stated earlier, program ran perfectly when I upgraded from Win7 to Win8 and also when I went from Office 2010 to Office 2013. The problem arose when I had to do a new OS install which generated a new registry. It was all downhill from there.  All other programs function fine.


    Paul


    Thursday, February 14, 2013 1:40 AM
  • Tried the install using ProcMon but didn't get anything out of it.

    It takes some effort to get used to but well worth it.   For example, a filter that you could try, using just the File Access trace is:  Operation Contains Write.   E.g. even if you didn't know the name of the program which was doing the write or anything about the files that it was modifying that essentially could give you a list of all the writes to a log that you may have already found, in order, and interleaved with any other writes to other files which you may not have found.   Besides the file name the trace record tells you when it was written, (date and timestamp in ms) and the length of the write.   In the case of diagnostic log records you can use the length of the write to correlate quite strongly with the length of the lines you are reading, so then be able to identify where in the trace a log record was generated.   Then, by removing your filter at that point and looking at more details such as Registry and the rest of the file access records, you can infer some of the details which could have been involved in the production of the message.

    In the case of your .dll registration you could use a filter of the Registry records for just that regsvr32.exe program name.   To see any changes that it made you could further refine that with  Operation Is RegSetValue.   Or if you wanted more detail such as RegQueryValue  as well add that too or just use  Operation Begins with Reg.   And so on.

    For a different view of your registration problem you could use DependencyWalker to profile the execution of  regsvr32.exe  with those arguments.   Sometimes that highlights that a problem reported by the regsvr32 command is not in the module that you might have assumed.   ; }

     
    Good luck

     
    Robert
    ---

    Thursday, February 14, 2013 3:35 AM
  • Micheal reported that registering under the system account using psexec succeeds while in a normal cmd window as admin it doesn't. The dependency walker log from Paul shows a missing file IESHIMS.DLL. That file appears to be part of Internet Explorer and is in more cases a source of registration troubles according to a quick google search.

    Does the system account not depend on IESHIMS.DLL somehow while all other accounts do?

    Ronald

    Thursday, February 14, 2013 12:37 PM
  • Does the system account not depend on IESHIMS.DLL somehow while all other accounts do?

    Don't know.   That would be a job for ProcMon too to help you figure out what the difference is.  Note that ProcMon traces can be saved as .pml files then opened concurrently in separate windows and compared that way.

    For a guess I would wonder if  IE  was unchecked as a component in Windows Features.  E.g. I know that hides iexplore.exe and any shortcuts for it and it is in the same directory that ieshims.dll is normally found in, so perhaps that is another consequence of trying to hide IE on your system?

    However, without seeing the log I would also wonder if that missing file is really what is causing a problem.   E.g. it is awfully easy to get distracted by red herrings when tracing.   ; )

     
    Good luck

     
    Robert
    ---

    Friday, February 15, 2013 12:46 AM
  • I haven't seen any reaction nor any progress on this issue now for >3 months so I guess we can officially declare OSASync dead (at least for Outlook versions >=2013 on Windows 8). I doubt we will see any fix or upgrade any more  allowing us to get OSASync functional, will we?

    R.I.P. OSASync- you are still being missed!

    M.


    • Edited by mmo17 Sunday, May 05, 2013 2:11 PM
    Sunday, May 05, 2013 2:10 PM
  • Paul,

    I dind't read the complet post but your answer can possible found at http://support.microsoft.com/kb/2792179

    Your problem is the missing Msaddndr.dll file which is no longer part of the MS-Office 2013 installation. See the kb article. It took me several day's to find out what was mising.

    Success


    Rob

    Wednesday, September 04, 2013 7:01 AM
  • Thank you all for taking the time to research this.  This thread has been the most helpful.

    I was able to download the Msaddndr.dll file off the internet

    Open a CMD windows as an administrator

    change directory to Msaddndr.dll file

    Regsvr32 Msaddndr.dll

    change directory to the osasyncpro.dll file

    regsvr32 osasyncpro.dll

    When it worked I didn't believe it :-)

    Jared

    Friday, September 06, 2013 10:11 PM