locked
Word automation under asp.net 1.1.4322 & Vista 64-bit

    Question

  • (this problem was solved, please refer to my later reply down in this thread)

    We have an asp.net 1.1.4322 application running successfully under Windows XP Pro 32-bit , Windows Server 2003 32-bit and Windows Vista Ultimate 32-Bit.

    In this application we are successfully generating/saving/opening Word documents, and we were able to successfully upgrade from Word 2000 to Word 2007 without problems, under both platforms.

    When installing and running the same application under Vista SP1 64-bit we faced a problem with automating Word. We tried giving all permissions possible, we tried impersonating in Web.Config, we tried running the IIS process as Administrator, we searched the internet and tried many solutions we found out there, but nothing seemed to fix the problem.

    Investigating under Task Manager, I can see that WINWORD is launched as:
    "C:\Program Files (x86)\Microsoft Office\Office12\WINWORD.EXE" /Automation -Embedding

    but the code crashes at a line like this:
    oDoc = oWord.Documents.Add(ref documentTemplate, ref oMissing, ref oMissing, ref oMissing);

    Generating this error:
    COMException (0x800a13e9): Word has encountered a problem.

    I have a feeling that this has to do with 32-bit/64-bit system dlls related to the Dcom Launcher, and during my search I came across this article which suggested checking some dlls and making sure they match the same version:
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;244264

    I checked those dlls under my Vista 64-bit installation and found them not matching. I was even missing olepro32.dll under the System32 folder.

    Would someone experienced here confirm whether my doubts are correct, or what other solutions I should be looking at?

    And any idea how I can replace oleaut32.dll? I was trying to replace this file under my Vista installation with another version but couldn't do it - even in Safe Mode. Turning off the DCom Launch service didn't even help and the file was still in use.

    Appreciate all help and suggestions provided.
     
    Thanks
     
    • Edited by GoodSmith Wednesday, February 25, 2009 8:58 PM
    Monday, December 08, 2008 11:31 PM

Answers

  • Wow, I have finally succeeded to solve this problem !!

    Here is what I did:

    First, use regedit (from the SysWOW64 folder) to search the registry for the CLSID(s) related to the command "WINWORD.EXE /Automation" , you might find more than one of them.
    (in my case this was: {000209FE-0000-0000-C000-000000000046} and {000209FF-0000-0000-C000-000000000046})

    Under those keys in HKEY_CLASSES_ROOT\CLSID\, add a string value AppID = {same value as the IDs}

    Then under HKEY_CLASSES_ROOT\AppID\ create a new key (folder) for each of these IDs, and inside each of them add a string value: RunAs = Interactive User
     
    Next go to Dcomcnfg (from the SysWOW64 folder) and search for those IDs. (there might be a third ID related to Winword.exe), in my case this was {00020906-0000-0000-C000-000000000046}.
    Note all those IDs, then right click on each of them, Properties, Security, and edit both the launch & access permissions to add and give Network Service and Interactive full permissions.

    The solution sounds so logical, it amazes me that Microsoft Support couldn't figure it out, and that no post on the internet was able to outline this solution.

    I hope others will benefit from this, specially with automating other applications too. I guess you just follow the same principle and search for the related commands (with /Automation) in the registry.
     
    It took me 4 stressful weeks until I finally figured this out on Christmas !
     
    Cheers!
    • Marked as answer by GoodSmith Saturday, December 27, 2008 8:07 AM
    Saturday, December 27, 2008 8:06 AM

All replies

  • .NET 1.1 is incapable of running in a 64-bit mode, so it should remain 32-bit throughout the pipeline...

    If your site is pure code (no .NET 1.1 DLLs uploaded to the web server), Vista might be trying to run it via ASP.NET 2.0 (which is pre-installed on Vista) in 64-bit mode.  If you suspect this may be the case, it should be possible to force it to run in 32-bit mode via the IIS settings.

    Have you had any success with Vista 32-bit?

    -Ryan
    Tuesday, December 09, 2008 12:10 AM
  • Thanks Ryan for the reply.

    The application is running under an application pool that is using .Net Framework v1.1 and has "Enable 32 bit Applications" set to True. If that's what you mean by forcing it to run in 32-bit mode then I guess it's already set, unless you meant it to be done in another way.

    I am currently setting a Vista Ultimate 32-bit testing environment. It's very time consuming. In the meanwhile I hope someone can have an idea about this issue.

    Thanks.

    Tuesday, December 09, 2008 6:57 PM
  • I have tested our application under Vista Ultimate 32-Bit RTM. Word automation worked perfectly fine without any problems.

    I have confimred the DLLs under Vista's default installation:

    The 4 files under System32 folder:

    asycfilt.dll 6.0.6000.16386 Nov 2 2006 1:46 AM
    oleaut32.dll 6.0.6000.16386 Nov 2 2006 1:46 AM
    olepro32.dll 6.0.6000.16386 Nov 2 2006 1:46 AM
    stdole2.tlb (unknown)      Nov 1 2006 11:29pm

    As you see, the DLLs match the same date and version number, while under Vista Ultimate 64-Bit SP1 (where it's not working) I have noticed that one of them didn't match.

    According to this article:
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;244264

    these files should be matching, so I am not sure if this would be the real cause of the problem, or that it's a totally a different issue.

    Until I find a way to unify/update the DLLs under Vista 64-bit, I am still hoping someone can provide further useful information - in case my thoughts are irrelevant.

    Thanks

    Tuesday, December 09, 2008 10:42 PM
  • What happens if you fully patch the 32-bit Vista?

    The versions may have become inconsistent due to a security update or other fix included in SP1.  This shouldn't normally break things.  If it breaks 32-bit Vista, then it's time to call Microsoft...

    -Ryan
    Tuesday, December 09, 2008 10:50 PM
  • I was able to synchronize those 4 files under Vista Ultimate SP1 64-bit, replacing them under SysWOW64 with those from Vista Ultimate 32-bit, but unfortunately that didn't fix the problem :(

    I am totally lost now and have no idea what's causing this problem. Is it a patch in SP1 that missed up things, or is it the 32bit/64bit conflict?
    Wednesday, December 10, 2008 6:21 PM
  • It could be either, at this point.  I would try patching the 32-bit OS with SP1 to see if it breaks... if it does, then you know the patch broke something.

    In any case, you're probably going to have to call Microsoft on this one... it's not likely that outsiders are going to have the resources to fix conflicts between Microsoft's DLLs.

    -Ryan
    Wednesday, December 10, 2008 6:28 PM
  • I am installing Ultimate 32-bit now and will be patching it with SP1. In either case I think I will be calling Microsoft. What's the best way to call them?
    Wednesday, December 10, 2008 7:12 PM
  • GoodSmith,

    I noticed the support article you referenced said ActiveX error which means the code runs in IE so you need IE32bits running because since there is no 64bits Office all such components are in x86.  Check below about 64bits limitations.


    http://support.microsoft.com/kb/282423/en-us


    Asp.net MVP, MCPD Web C#, MCTS TFS, MCITP BI and DBA
    Wednesday, December 10, 2008 7:14 PM
  • Caddre, IE was running under 32-bit mode. I checked that in Task Manager and it's iexplorer.exe*32
    Wednesday, December 10, 2008 7:18 PM
  • Can you also check for the 64bits version and make sure you code is not trying to use the wrong one.


    Asp.net MVP, MCPD Web C#, MCTS TFS, MCITP BI and DBA
    Wednesday, December 10, 2008 7:22 PM
  • This is to confirm that patching Vista Ultimate 32-bit with SP1 didn't break things. Word automation was still working properly on it.

    I have seen several posts on the internet for people having problems automating other office applications (like Excel) on 64-bit systems.

    Caddre, what exactly should I be checking and where?

    Thanks for all your help.
    Wednesday, December 10, 2008 9:16 PM
  • The IE folder is in Windows because it is part of Windows. I have good news and bad news there is 64bits third party Word component but it is expensive and there is a way you could run the code in process start it runs in IE but it will show in your application.  So start with the CLR debugger it will show you where the issues are because I had a user with .NET 1.1 web service with many third party dlls and all that was needed was permission for the Asp.net runtime.


    http://support.microsoft.com/default.aspx/kb/893657

    http://gregdotnet.blogspot.com/2005/12/rocky-transition-to-64-bit.html

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3560016&SiteID=1


    Asp.net MVP, MCPD Web C#, MCTS TFS, MCITP BI and DBA
    • Marked as answer by Zhi-Xin Ye Monday, December 15, 2008 12:34 PM
    • Unmarked as answer by GoodSmith Saturday, December 27, 2008 8:07 AM
    Wednesday, December 10, 2008 9:46 PM
  •  
    I am still trying to solve this problem myself without any luck so far.
     
    However I am trying to break the problem into small pieces to see where it fails exactly, and comparing how it works on a 32-bit system.
     
    I noticed the following:
     
    Lets take a web application with these 3 lines of code:
     
    object oMissing = System.Reflection.Missing.Value;
    Microsoft.Office.Interop.Word.ApplicationClass oWord = new Microsoft.Office.Interop.Word.ApplicationClass();
    oWord.Quit(ref oMissing, ref oMissing, ref oMissing);
     
    These 3 lines are the minimum just to start Word application from .Net and close it. Of course I have added a reference to the COM "Microsoft Word 12.0 Object Library".
     
    I opened Task Manager to monitor what processes are being called, then I complied and run the web application.
     
    On the 32-Bit system, the working process launches WINWORD.EXE and terminates it successfully. On a 64-Bit system, WINWORD.EXE*32 is called but it fails to terminate.
     
    A note that might help:
     
    under 32-bit , when debugging the application, I noticed the following value:
    oWord.StartupPath = @"c:\users\administrator\appdata\roaming\microsoft\word\startup"
     
    while under the 64-bit, oWord.StartupPath was empty.
     
    I tried different settings Under DCOMCNFG and IIS Manager. Under DCOM I modified the object 00020906-0000-0000-C000-000000000046 (WINWORD) so that the interactive user (Administrator) is used to run the application (this is how it works on 32-Bit system). However, WINWORD.EXE*32 kept lunching under NETWORK SERVICE and not terminating.
     
    Under IIS Manager I modified the application pool under which the application is running, changing the process identity from NetworkService to the Administartor account. Both w3wp.exe*32 and WINWORD.EXE*32 are now running under the Administrator account, but WinWord still fails to terminate. Also in this case I noticed that:
    oWord.StartupPath becomes @"c:\windows\system32\config\systemprofile\appdata\roaming\microsoft\word\startup"
     
    I have a feeling that the COM is not called properly. If this little issue is fixed then it's an important step to fix the whole problem.
     
    Another note: Based on a Microsoft support response to my issue, I tried importing the unmanaged codes into .Net assemblies using tlbimp.exe.
     
    I imported these files:
     
    (Microsoft.Office.Interop.Word) C:\Program Files (x86)\Microsoft Office\Office12\MSWORD.OLB
    (Microsoft.Office.Core)  C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE12\MSO.DLL
    (VBIDE)    C:\Program Files (x86)\Common Files\Microsoft Shared\VBA\VBA6\VBE6EXT.OLB
     
    I added the resulting dlls under the bin folder of my application and referenced them, but it didn't fix the issue.
     
    I hope all my work and trials so far will help someone guide me to a solution.
     
    Thanks
    Wednesday, December 24, 2008 10:25 AM
  •  The process running under Network Service needs to be resolved, I am assuming it is in your internal network because you are using reflection which require full trust so you could try local system account.  Which is a very high level permission account but your code is not running so you need to start with using admin level permissions in all the folders your application is using.


    Asp.net MVP, MCPD Web C#, MCTS TFS, MCITP BI and DBA
    Wednesday, December 24, 2008 1:25 PM
  • Hi GoodSmith,

    Have you tried to automate Word from a WinForm application on that same machine?

    Do you have any anti-virus software on that box which plugs into the Word application?


    VSTO Rocks!
    Thursday, December 25, 2008 2:52 AM
  • Wow, I have finally succeeded to solve this problem !!

    Here is what I did:

    First, use regedit (from the SysWOW64 folder) to search the registry for the CLSID(s) related to the command "WINWORD.EXE /Automation" , you might find more than one of them.
    (in my case this was: {000209FE-0000-0000-C000-000000000046} and {000209FF-0000-0000-C000-000000000046})

    Under those keys in HKEY_CLASSES_ROOT\CLSID\, add a string value AppID = {same value as the IDs}

    Then under HKEY_CLASSES_ROOT\AppID\ create a new key (folder) for each of these IDs, and inside each of them add a string value: RunAs = Interactive User
     
    Next go to Dcomcnfg (from the SysWOW64 folder) and search for those IDs. (there might be a third ID related to Winword.exe), in my case this was {00020906-0000-0000-C000-000000000046}.
    Note all those IDs, then right click on each of them, Properties, Security, and edit both the launch & access permissions to add and give Network Service and Interactive full permissions.

    The solution sounds so logical, it amazes me that Microsoft Support couldn't figure it out, and that no post on the internet was able to outline this solution.

    I hope others will benefit from this, specially with automating other applications too. I guess you just follow the same principle and search for the related commands (with /Automation) in the registry.
     
    It took me 4 stressful weeks until I finally figured this out on Christmas !
     
    Cheers!
    • Marked as answer by GoodSmith Saturday, December 27, 2008 8:07 AM
    Saturday, December 27, 2008 8:06 AM
  • I modified my solution so that only the specific entries under Dcomcnfg are given full permissions to Network Service and Interactive. I didn't feel comfortable giving those permissions to everything under My Computer.
    Wednesday, February 25, 2009 9:20 PM

  • I m sorry to open this again. I seem to face a very related problem in word automation.
    I have created a windows service which creates a sample word document (WORD 2007) and then converts it to a .doc file (WORD 2003 format) or a PDF file , based on requirement.  Let me post the sample code here:

    public static bool CreateTestDocDocument() 
            { 
                ApplicationClass wordApplication = null
                object missing = Type.Missing;             
                Document wordDocument = null
                bool sucess = false
                try 
                { 
                    wordApplication = new Microsoft.Office.Interop.Word.ApplicationClass(); 
                    string docFileName = @"C:\Myservice\Test.doc"
                    if (wordApplication != null
                    { 
                        wordDocument = wordApplication.Documents.Add(ref missing, ref missing, ref missing, ref missing); 
     
                        if (wordDocument != null
                        { 
                            SaveAs(wordDocument, string.Empty, docFileName, WdSaveFormat.wdFormatDocument97); 
                            sucess = true
                        } 
                    } 
                } 
                catch (Exception exp) 
                { 
                    Console.WriteLine("Message : " + exp.Message); 
                    Console.WriteLine("Inner Exception : " + exp.InnerException);                 
                } 
                finally 
                { 
                    wordDocumentUtil.Close(wordDocument); 
                    WordAppProvider.DisposeWord(); 
                } 
                return sucess; 
            } 
     
    public void SaveAs(Document document, string sourceFileName, string targetFileName, WdSaveFormat targetFileFormat) 
            { 
                object missing = Type.Missing; 
     
                try 
                { 
                    object targetFileNameObj = targetFileName; 
                    object targetFileFormatObj = targetFileFormat; 
     
                    object lockComments = false
                    object addToRecentFiles = true
                    object readOnlyRecommended = false
                    object embedTrueTypeFonts = false
                    object saveNativePictureFormat = true
                    object saveFormsData = true
                    object encoding = MsoEncoding.msoEncodingUSASCII; 
                    object insertLineBreaks = false
                    object allowSubstitutions = false
                    object lineEnding = WdLineEndingType.wdCRLF; 
     
                    if (document != null
                    { 
                        document.SaveAs(ref targetFileNameObj, ref targetFileFormatObj, 
                            ref missing, ref missing, ref missing, ref missing, 
                            ref missing, ref missing, ref missing, ref missing, ref missing, 
                            ref missing, ref missing, ref missing, ref missing, ref missing); 
                    } 
                } 
                catch (Exception exception) 
                { 
                    Console.WriteLine("Message : " + exception.Message); 
                    Console.WriteLine("Inner Exception : " + exception.InnerException); 
                    //msLog.Error(StringUtil.GetConcatenatedString("Unable to save the document ", sourceFileName), exception); 
                    //throw; 
                } 
            } 


    This piece of code works perfectly in my local machine which has windows XP (Sp2). It does create a test.doc file in the specified folder. But when I install this service in a machine which has Windows server 2008 (64bit OS), there seems to be problems. This is the error I am getting when it tries to execute the SaveAs method:

    The message filter indicated that the application is busy. (Exception from HRESULT: 0x8001010A (RPC_E_SERVERCALL_RETRYLATER)) 

    But if I execute the same piece of code in a console application in Windows server 2008, there is absolutely no problem. It successfully creates the test.doc file. There seems to be a problem only when I try to create the doc file through the installed windows service.

    I tried all the gymnastics for 2 whole days, and also came across this post, and did all that what GoodSmith did to solve his problem. But still in vain....:(

    Someone please help me with this..

    regards,
    abey
    Tuesday, March 17, 2009 10:35 AM
  • I've the same problem. I've applied all the proposed solutions so far including goodsmith's solution.

    I have asp.net 2.0 web application running on
    -Windows server 2003 64 bit version
    -IIS 6.0 64-bit
    -Microsoft Office 2007

    I am doing simple mail merge using WORD com object, I've given rights to all the keys bellow in DCOMCNFG:
    {000209FE-0000-0000-C000-000000000046}
    {000209FF-0000-0000-C000-000000000046}
    {00020906-0000-0000-C000-000000000046}

    tried to give full rights to Network Service, Interective User and Finally Everyone. Also tried with 'interactive user' as well 'launching user'. But I am still getting the same error of access denied. The exact errormessage is as bellow:

    Retrieving the COM class factory for component with CLSID {000209FF-0000-0000-C000-000000000046} failed due to the following error: 80080005.

    OR

    Retrieving the COM class factory for component with CLSID {000209FF-0000-0000-C000-000000000046} failed due to the following error: 8000401a.

    The strange thing is, when i run the same code in a test windows application on that server, it works fine!

    GoodSmith - can you tell your solution work with IIS 6.0 64-bit too?


    Do not Spam
    Friday, May 15, 2009 10:29 AM
  • Hi,

    I'm too having the same problem - I'm using .NET 3.5, Word2007, and WCF service.

    WCF is hosted in IIS 6.0, and it's trying to open document in Word (and after that issue a "saveAs", but it never gets to there).

    Using the solutions above I managed to get rid of most of the errors, but now it's stuck on

    myWordApp.Documents.Add  method.

    I can hear a message box popping out when this line is executed, but I can't see what it is because it's in automation... When I try to open the file manually with Word it opens ok, and when I try to open it after a call to Add() it's says the file is in use.

    If some of you found out a solution (for anything similar) - please post it! Thanks!

    Friday, July 10, 2009 12:00 PM
  • GoodSmith's answer worked for me for Word.  Now if only I could get the same results with Excel.

    edit: figured it out for Excel too. Use GoodSmith's answer, using these IDs...
    {00020812-0000-0000-C000-000000000046}
    {00020820-0000-0000-C000-000000000046}
    {00024500-0000-0000-C000-000000000046}

    In dcomcfg, {00020812-0000-0000-C000-000000000046} may be listed with its friendly name "Microsoft Excel Application".  Same goes for {00020906-0000-0000-C000-000000000046} as "Microsoft Word Application".  It depends on the machine as I've had two Microsoft Server 2008 test machines show different names in DCOM.
    Friday, July 17, 2009 8:46 PM
  • Thank You very very very much, it took me 7 hours testing searching setting searching... until your post

    Thanks.
    Wednesday, August 12, 2009 10:56 AM
  • I have service which used office automation to convert office documents to pdf.
    I've given rights to all nesseccary keys in Dcomcnfg and everything works fine till some user is logged to mashine where service is installed. But since user is logged off service stopped working with com exeption as if it doesn't have permissions.
    Could anyone help me with this?
    Monday, February 01, 2010 7:53 AM
  • Hi Goodsmith

    Are you able to e-mail screenshots of your registry editor.

    Regards

    Vikas

    Tuesday, July 13, 2010 3:22 AM
  • Hi Smith

    Thanks very much. It's really amazing. I was also facing same problem and was googling for almost two week. Once again thanks a lot.

    I applied your steps on Win XP and everying is working fine. But when i deployed my web serice (office automation) Windows Server 2008 getting same error message

    Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046} failed due to the following error: 80070005. 

    I did same registry settings on Win Server 2008 but it's not working, getting above error

    Please help me!!!!!!!!!!

    Thanks,

    Santosh J (MCP)

    Wednesday, August 04, 2010 1:09 PM
  • Hi Rose,

    instruction given by smith is really working for Win XP but not if you deploy your application on win server 2008

    I am looking for alternative way that by using OpenXML

    Thanks,

    Santosh J.

    Friday, August 06, 2010 3:24 PM
  • I found this on another message board, perhaps it will help.  Run this:

    mkdir c:\windows\syswow64\config\systemprofile\Desktop

    I couldn't get Word automation to work until I created this directory; apparently the directory is needed in the automation process.  Creating the directory solved everything for me.

     

    Friday, August 27, 2010 8:30 AM
  • Hi there - I am Sitting with the same Probelm .

    Error Message : Retrieving the COM class factory for component with CLSID {000209FF-0000-0000-C000-000000000046} failed due to the following error: 80080005.

    I have tried everything you said in your post, but still no luck.

    We are running an Windows 2008 64bit Server and Office 2007.

    I am Trying to do a mail merge in Word. but get this error on this line.

    wrdApp =

    new Word.Application();

    Works on Dev and another Server 2008 32bit.

    Any help would be appresiated.

    Regards

    Theo

     

     

    Thursday, September 02, 2010 1:44 PM
  • Hi Ok - Goodsmith's post did work - I forgot to check one of them as Interactive User.

    But now sitting with a new problem.

    Getting this error after a couple of hours of inactivity - then I just go into the com object and reselect the interactive user and then it works again.

    but I cannot do the the whole day for the users to work. anyone have any ideas.

    Retrieving the COM class factory for component with CLSID {000209FF-0000-0000-C000-000000000046} failed due to the following error: 8000401a

     

     

    Tuesday, September 07, 2010 9:54 AM
  • Hi Theo,

    I am creating an instance of AutoCAD .. and it throws the same error ....

    Retrieving the COM class factory for component with CLSID {6D7AE628-FF41-4CD3-91DD-34825BB1A251} failed due to the following error: 80080005

    Can you please help me out in resolving this ?

    Thanks

     

    Tuesday, September 14, 2010 12:42 PM
  • I'm posting this in case it helps others who have problems similar to me. I was getting this error when trying to script Word automation:

    Microsoft VBScript runtime error: Permission denied: 'CreateObject'

    I'm running Windows Server 2008 R2 (64 bit) and had installed the 32 bit version of Word 2010 because I read that Microsoft recommend it over the 64 bit version. I was unable to get scripted automation working according to GoodSmith's solution.

    Then it occurred to me that perhaps the complications of WOW64 and the many extra registry entries it creates were the problem. I researched the 64 bit version of Office and found that issues were only relating to Office add-ons that hadn't been re-written to be 64 bit compatible and there isn't actually anything problematic with the Office product itself.

    So I installed the 64 bit version of Word 2010, skipped the registry tampering (I undid the changes made previously) and just went into dcomcnfg and changed the Security permissions for "Microsoft Word 97 - 2003 Document" and from the Identity tab selected "The interactive user". This was enough to give the user account that automation runs under the necessary permissions. I didn't even need to create the "Desktop" folder mentioned elswhere in this thread.

    I still owe GoodSmith gratitude for finding the solution with dcomcnfg. Thank you.

    Tuesday, January 04, 2011 11:50 AM
  • hi? I saw the solution u gave it must have saved so many lives..thank you However am running an aspnet 3.5 application on WINDOWS 7 . and am getting the exact same errors trying to automate  a word template...please can you help me with the steps to take seeing that the features in vista are quite differnt in from windows 7.?? i cant see some of the features here..Have been working on this for exactly 4 weeks now.Thank you in advance....
    Sunday, February 27, 2011 7:25 AM
  • Goodsmith.  Thanks so much for the valuable information.  If it wasn't for you pointing me in the right direction, I would have NEVER gotten it to work. However, I had to modify your solution in order to get it to work for me.  I documented my steps, and here is what I did.

    BTW, I am running all this code on a Windows Server 2003 R2 64 Bit Edition, with Service Pack 2 and Office 2007.

    In REGEDIT:
    Use regedit (from the SysWOW64 folder) to search the registry for the CLSID(s) related to the command "WINWORD.EXE /Automation" , you might find more than one of them.

    In my case this was:
    {00020906-0000-0000-C000-000000000046}, {000209FE-0000-0000-C000-000000000046} and {000209FF-0000-0000-C000-000000000046}

    {00020906-0000-0000-C000-000000000046} should have local path to WINWORD.EXE. The other two should have same path, with "/Automation" added on the end of it.

    Under those keys in HKEY_CLASSES_ROOT\CLSID\, make sure the AppID points {00020906-0000-0000-C000-000000000046}

    If not add a string value AppID = {00020906-0000-0000-C000-000000000046}. This will point to the main WINWORD.EXE key.

    In DCOMCONFIG:
    Component Services > My Computer > DCOM Config

    Scroll to each of the three above keys, right click > Properties > Security
    Edit the Launch, Access, and Configuration permissions to add and give NETWORK SERVICE and INTERACTIVE full permissions.

    Next, click on the Identity Tab (on all three keys) and check the "This User" radio button. User should be anyone with Administrator rights.  Insert the password, confirm and click APPLY.

    This should do it.

    Again. Thanks for the pointers.  I couldn't have done it without your info. Hope this helps somebody else.

     

    Thursday, March 03, 2011 8:26 PM
  • Awesome  Thanks.

     

    I'm on Windows 7 64bit, and the Identity Tab change solved the problem for me.

     

    Thanks

    Tuesday, May 17, 2011 3:40 AM
  • Thanks Goodsmith and nfway.... Really this solution works
    Sunday, June 26, 2011 10:39 AM
  • Instead of changing Registry settings the solution is:

    ・Windows 2008 Server x64

    Create the folder:  C:\Windows\SysWOW64\config\systemprofile\Desktop

    ・Windows 2008 Server x86

     Create the folder:  C:\Windows\System32\config\systemprofile\Desktop

    Before moving our application to a Windows 2008 server it was running on a Windows 2003 server where the folder C:\Windows\System32\config\systemprofile\Desktop existed.

    This worked out great for me!!

    Sources:

    http://social.msdn.microsoft.com/Forums/en/innovateonoffice/thread/b81a3c4e-62db-488b-af06-44421818ef91

    http://social.msdn.microsoft.com/Forums/en-US/netfx64bit/thread/545dd81f-e80a-48b0-89a1-dafcd72e269d/


    turbodude
    Friday, August 12, 2011 10:36 AM
  • Thanks to all above! Hours of web searching was finally productive. As simple as creating a folder!

    My situation was a little different in that I was having problems running automated tests in Visual Studio 2010 (vs2010). The Team Build Server would happily run the tests in interactive mode, but would always fail when part of the automated mstest and msbuild process.

    The specific exception I was getting was just "Word has encountered an error" when trying to create a new document using Documents.Add.

    Hope this comes in useful in future for anyone searching for these words.

    David

    Wednesday, January 11, 2012 4:32 AM
  • I still had to do one thing to resolve the same subsequent issue people above had:

    Retrieving the COM class factory for component with CLSID {000209FF-0000-0000-C000-000000000046} failed due to the following error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)).

    My application was running under IIS, and I had to set the Identity of the IIS Application Pool from Network Service to an account which is an administrator on the machine.  The alternative to this which also works is turning on impersonation in the web.config.

    Hope this helps!

    Friday, August 03, 2012 9:25 PM
  • Thanks for posting this solution, I applied the same logic to Excel and it works like a dream, like you say it sounds so logical.  I have one question, we are a software company that distributes our software to other companies therefore I'm slightly worried in respect of support from Microsoft.  Are they (Microsoft) happy with this solution as I'd like to say to our clients that everything is ok to recommend your fix?

    Cheers

    Paul

    Friday, August 10, 2012 9:04 AM
  • thank you so much, this really helped me a lot :)
    Friday, November 09, 2012 1:04 PM