index > 64-Bit .NET Framework Development > Word automation under asp.net 1.1.4322 & Vista 64-bit

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

(this problem was solved, please refer tomy later reply down in this thread)

We have anasp.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 andrunning the same application under VistaSP164-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

butthe 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 versionbut 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 byGoodSmith Wednesday, February 25, 2009 8:58 PM
Edited byGoodSmith Tuesday, December 09, 2008 10:43 PM

GoodSmith

Wow, Ihave finally succeeded to solve this problem !!

Here is what I did:

First,useregedit(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 astring value: RunAs = Interactive User

Next go to Dcomcnfg (from the SysWOW64 folder) and search for those IDs. (there might be a third ID relatedto Winword.exe), in my case this was {00020906-0000-0000-C000-000000000046}.
Note allthose IDs, then right click on each of them, Properties, Security, and edit both thelaunch & access permissions to add and giveNetwork 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 guessyou 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 byGoodSmith Saturday, December 27, 2008 8:07 AM

GoodSmith

.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

Ryan Lamansky

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 Ultimate32-bit testing environment. It's very time consuming. In the meanwhile I hope someone can have an idea about this issue.

Thanks.

GoodSmith

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.dll6.0.6000.16386 Nov 2 2006 1:46 AM
oleaut32.dll6.0.6000.16386 Nov 2 2006 1:46 AM
olepro32.dll6.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 realcause 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 areirrelevant.

Thanks

GoodSmith

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

Ryan Lamansky

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?

GoodSmith

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

Ryan Lamansky

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?

GoodSmith

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

Caddre

Caddre, IE was running under 32-bit mode. I checked that in Task Manager and it's iexplorer.exe*32

GoodSmith

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

Caddre

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.

GoodSmith

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 byZhi-Xin YeMSFT, ModeratorMonday, December 15, 2008 12:34 PM
Unmarked As Answer byGoodSmith Saturday, December 27, 2008 8:07 AM

Caddre

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

GoodSmith

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

Caddre

Hi GoodSmith,

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

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

VSTO Rocks!

devilxelloss

Wow, Ihave finally succeeded to solve this problem !!

Here is what I did:

First,useregedit(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.

It took me 4 stressful weeks until I finally figured this out on Christmas !

Cheers!

Marked As Answer byGoodSmith Saturday, December 27, 2008 8:07 AM

GoodSmith

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 permissionsto everything under My Computer.

GoodSmith

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:

publicstaticboolCreateTestDocDocument()

{

ApplicationClasswordApplication=null;

objectmissing=Type.Missing;

DocumentwordDocument=null;

boolsucess=false;

try

{

wordApplication=newMicrosoft.Office.Interop.Word.ApplicationClass();

stringdocFileName=@"C:\Myservice\Test.doc";

if(wordApplication!=null)

{

wordDocument=wordApplication.Documents.Add(refmissing,refmissing,refmissing,refmissing);

if(wordDocument!=null)

{

SaveAs(wordDocument,string.Empty,docFileName,WdSaveFormat.wdFormatDocument97);

sucess=true;

}

catch(Exceptionexp)

{

Console.WriteLine("Message:"+exp.Message);

Console.WriteLine("InnerException:"+exp.InnerException);

}

finally

{

wordDocumentUtil.Close(wordDocument);

WordAppProvider.DisposeWord();

}

returnsucess;

}

publicvoidSaveAs(Documentdocument,stringsourceFileName,stringtargetFileName,WdSaveFormattargetFileFormat)

{

objectmissing=Type.Missing;

try

{

objecttargetFileNameObj=targetFileName;

objecttargetFileFormatObj=targetFileFormat;

objectlockComments=false;

objectaddToRecentFiles=true;

objectreadOnlyRecommended=false;

objectembedTrueTypeFonts=false;

objectsaveNativePictureFormat=true;

objectsaveFormsData=true;

objectencoding=MsoEncoding.msoEncodingUSASCII;

objectinsertLineBreaks=false;

objectallowSubstitutions=false;

objectlineEnding=WdLineEndingType.wdCRLF;

if(document!=null)

{

document.SaveAs(reftargetFileNameObj,reftargetFileFormatObj,

refmissing,refmissing,refmissing,refmissing,

refmissing,refmissing,refmissing,refmissing,refmissing,

refmissing,refmissing,refmissing,refmissing,refmissing);

}

catch(Exceptionexception)

{

Console.WriteLine("Message:"+exception.Message);

Console.WriteLine("InnerException:"+exception.InnerException);

//msLog.Error(StringUtil.GetConcatenatedString("Unabletosavethedocument",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 inWindows 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

XrayProteins

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

Kiran Beladiya

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!

veljkoz

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.

Deriven

Thank You very very very much, it took me 7 hours testing searching setting searching... until your post

Thanks.

robertkwapiszewski

You can use google to search for other answers

Custom Search

More Threads

• Access registry created by 32 bit program

• How to determine if running on 64Bit?

• Does GetClickablePoint work in 64-bit environment?

• Windows Service EXE x86 + Assembly (AnyTarget)?

• Compile .NET to Run On 64 Bit Environment

• Using the Athelon AMD 64 Processor on a 32 bit Mother board.

• Visual Studio .Net 2005 32 bit on 64 bit machine

• x64 platform support in VS2005 after installation?

• Getting Smart on 64bit .NET

• Connections to access on x64 are not possible.