I developed an application which grabs some data from our server, spits it out into an excel sheet, and emails that sheet to specific users. I needed this application to launch every 30 minutes so I setup a scheduled task on our server to run this application. What I can't figure out is this: The application runs (I can see that the data is being collected from our database (marked as hit in a [Processed] column)), but it will not create the excel file, and consequently does not send the email.
I need to figure out why so this process can work for me. A few things to note:
1.) I am an admin for this machine. (double checked my authorities)
2.) Excel IS installed on this machine.
3.) The scheduled task doesn't work, but if I manually run the program it executes perfectly.
4.) Proper versions of .Net are installed.
5.) Other scheduled task exist that do similar operations and have no issues.
The server is 2008 Enterprise.
Related
Our normal workflow is to use a Windows Scheduled Task to:
convert files from rtf to pdf in bulk
manipulate the pdfs to add barcodes
aggregate into a single pdf
then send for printing
This was working fine on Windows Server 2008, but since our upgrade to Windows Server 2019 (end of life and whatnot) we've run into a whole host of issues. We're now falling down at the first hurdle- even instantiating the Word OLE client. The error isn't consistent - one day the process will complete successfully, the next it will fail immediately.
Our tasks trigger a Dyalog APL workspace, where the code to be executed sits. For debugging purposes, I have set up a simplified version which is doing the following:
tries←0 ⍝ Initialise the try counter
Log'Attempting to create Word instance' ⍝
:Repeat ⍝ Keep trying to...
Word←⎕NEW'OleClient'(⊂'ClassName' 'Word.Application') ⍝ Create the Word Client instance
Word.Visible←1 ⍝ making the application visible
tries+←1 ⍝ and incrementing the try counter each time
Log'Try: ',⍕tries ⍝
:Until #.Word.PropList∊⍨⊂'Documents' ⍝ Until it has seemingly created successfully
:OrIf tries≥maxTries_create ⍝ ... or the tries have exceeded the maximum (currently 5)
⍝
'doc open'delayAndLog dl_open ⍝ With an optional external delay...
myWordDoc←Word.Documents.Open⊂docPath ⍝ open the specified test doc
⍝
'doc close'delayAndLog dl_close ⍝ With an optional external delay...
myWordDoc.Close 0 ⍝ close the doc (not saving)
⍝
'application quit'delayAndLog dl_quit ⍝ With an optional external delay...
Word.Application.Quit 0 ⍝ quit the word client
The various delays are held externally in a config file. I didn't include the reading of this config file, as essentially what is shown here is the substance. Note: I retry creating the instance as sometimes I've found that it only instantiates with the barebones methods. Putting a delay in, or retries seemed to fix this.
This piece of code, will run completely fine in my non-prod servers (and even sometimes in production). Today, it will run fine when I am running it through the IDE, but when running as a Windows Scheduled Task it will report a DOMAIN ERROR when opening the document.
My observations are that it briefly creates the WINWORD.exe, i.e. you can see it in the task manager, the status turns to "suspended", then it disappears. In the event viewer, we see the following:
Event Viewer - ntdll application fault (id: 1000)
Things I've tried so far
Rebooted the server (yes, you joke, but turning it off and on again is the first thing we should always try)
Repaired Office
Reinstalled Office
Tried configuring the task to run as a different user (myself, with local admin rights)
Tried configuring the task to run on a different server.
Tried configuring the task to run with a higher priority.
Making the Word instance visible, to see if there are any error pop-ups.
Built a simplified version of the task (see above) to ensure it's not just the overall complexity of the main task causing confusion.
Disabled "automatic inking" on Microsoft's recommendation
Captured procmon logs of the error (awaiting Microsoft's review)
Versions currently installed:
Word: Microsoft Word 2019 MSO (16.0.10374.20040) 64-bit
Dyalog APL: 16.0.35960.0 32-bit Unicode
Windows Server 2019 Standard Version 1809. OS Build 17763.1697.
Any help would be really greatly appreciated on this one as I feel like I'm tackling Schrödinger's OLE Client. Thanks in advance.
That is a crash in Word.
There might be crash dump files in c:\Users<yourname>\AppData\Local\Temp\ or c:\Users<yourname>\AppData\Local\CrashDumps.
At your company, if you have any C developers who can use Visual Studio or Windbg, they could open the dump file and see if it gives any clues.
If not, I could take a quick look if you send it to Dyalog Support.
This is just a guess...Have you tried increasing the size of the Desktop heap? Please see this blog post:
https://learn.microsoft.com/en-us/archive/blogs/ntdebugging/desktop-heap-overview
Regards,
Vince
I have a workbook that contains a macro that I would like to run once a week automatically.
I have set up the workbook_open event to run the macro and the code itself runs as I would like it to.
My question is how to schedule this to automatically run on a schedule. I have setup a task in windows task scheduler which does not seem to run reliably (i've tried this on a few different projects over the years and never get great results).
My desire is to have my personal desktop run this task whether or not I am logged in. (Obviously the computer needs to be powered on which is no problem. Also, I am the only one that uses this computer, no concern about someone else being logged in)
Is there a more robust way of doing this or am I stuck with task scheduler? If so, has anyone else had better success with it that might be able to help me out?
Task scheduler seems to work only intermittently although the "history" shows it is triggered and run at the desired times. Part of the code saves a file to a location with a date stamp and there are not files for each trigger in the scheduler history.
When logged off , the task is executed without loading the user profile.
Maybe this is the answer for you.
It's Japanese. Can you use google translate?
enter link description here
You have to make the directory.
If you use 32bit Excel : %SystemRoot%\System32\config\systemprofile\Desktop
If you use 64bit Excel : %SystemRoot%\SysWOW64\config\systemprofile\Desktop
For anyone that might run across this. I've been using a 3rd party task scheduler which is much more reliable in my experience. There are many out there but i use robointern. robointern website
I have a vbs script that opens Excel and runs a vba script. It works fine on Windows 7, both when run manually and as a task in Task Scheduler. It works fine when run manually on Server 2008 but when I run it as a scheduled task, it hangs. I added some rudimentary logging to the vbs file and it appears to hang as soon as the vba script is run. Excel is (apparently) opened fine.
I have already:
Chosen the correct directory for "Start in"
Chosen "Run with highest privileges"
Added the "Desktop" folder to C:\Windows\SysWOW64\config\systemprofile
Made sure the user that the task is set to run as has full access to all of the files and folders touched by the script.
Tried all possible variations of this: Task Scheduler running but not finishing or working properly VBscript
Set to "Run whether user is logged in or not"
(note: before adding the desktop folder the task "ran" successfully but didn't actually do anything it was supposed to)
Any ideas?
we have a web service hosted on iis 6.0, it open a specify excel template file. And a macro "t.xla" should retrieve data from database after excel opened, ready for client to download.
The issue is that the macro seems not run. The code is like following (i'm not in company now, so i just write pseudocode):
System.Diagnostics.ProcessStartInfo pStartInfo = new ProcessStartInfo(excelAppPath, excelTemplatePath);
//nomal window is in debug mode, createNoWindow will be used in product envirionment
pStartInfo.WindowStyle = ProcessWindowStyle.Nomal;
System.Diagnostics.Process process = new Process();
process.Start(pStartInfo);
log.Info("Excel Process was started");
when i running this code,
1)could see excel.exe was started from task manager.
2)excel.exe creates no window on the desktop, someone says it should be, because of the iis limited.
3)I'm sure that the macro "t.xla" hadn't run, because there is no log exist which should be written by macro.When i doubleclick any one of the excel template, logs will be found.
Now iis worker process is run in local SYSTEM account , and already Enable IIS Admin Service to interact with desktop. Also the directory which the template file and log file in could be written by everyone
Could anyone give me some advise? Thanks in advance.
You might want to use another account other than local system -- that way you can log in as that account and try the same thing to see if any dialogs or errors are popping up that might be preventing things from moving further along, such as macro security settings. Microsoft does not support running Excel in this manner, but that doesn't mean you can't get it work. Check out this article, it covers many more details to consider: http://support.microsoft.com/kb/257757
I have been looking at an issue for a week straight and have been unable to figure it out and I am desperate for the fix.
On a client site, we have two environments: UAT and PROD. UAT works perfect (Please keep this in mind). We are now trying to deploy the solution to PROD but certain parts of the solution are not working.
We have developed an asp.net application that we provide to clients to allow them to invoke SSIS packages (there are a couple of drop downs that they first select then click a button named "invoke").
When the user clicks the Invoke button, a batch file named InvokeSSIS.bat is called that assembles a command line call to dtexec with the appropriate parameters.
I'm having a problem with a particular package that is responsible for calling an executable which generates a spreadsheet that i will be importing into my system.
The executable is on an mapped H:\ drive.
I have modified the InvokeSSIS.bat batch file to capture the command the batch file is generating. If I execute this command from the command line, it works perfectly. From the webapp Invoker, it executes the package but the tasks responsible for calling the executable doesn't execute as the entire package takes only 1 second to complete (whereas it should take about a minute.)
The executable DOES have a GUI, but it is NOT interactive. This is because when you call the GUI with specific parameters, it automatically runs in batch mode and executes a macro used to generate the desired spreadsheet.
I know this is ok because it works on the UAT server AND it works from the command line!
I have checked the permissions on the executable (bu right-clicking the executable and clicking properties.) I have granted Full Control on the executable to the same user specified as the identity tab of the application pool i am using.
Can someone please help me? As I said I am dying over here!
Please let me know if you have any ideas or what other info you need.
Environment (both UAT and PROD)
OS: Windows Server 2003
IIS 6
asp.net 2.0
SQL Server 2008
Thanks!
Steve
You can't use a mapped drive with IIS.
You must use the \\servername syntax to reach files on other systems.
I agree with user544284 that this is at least in part a mapping issue. I'll ignore for a minute the complete insanity of having a web application call a batch file to start an executable that's on a remote network drive through a drive letter mapping.
Most likely the UAT box has something set up that maps that drive letter for you which Prod is missing.
The only other possibility is a security violation is occurring. Running .exe's from a network drive is generally frowned on. Do the two environments have the exact same version of windows? Are they configured the same with regards to UAC? Any differences here are going to be important.
Which brings up an interesting thought. I wonder if someone logged in to the UAT server using the same account credentials the app pool is using and added the ip address of the machine where the exe lives to the list of "Local Intranet" sites... Or, if they installed SSIS on the UAT server itself.
Just because YOU can log in to the server and run it on the command line means nothing. You have to find out if the drive letter is mapped at all for the user that the web app is running under and whether that user has the required security bits and whether the local OS will allow it regardless.
Okay, I can't ignore it: hairbrained is the nicest adjective I can come up with for this "architecture". Do yourself a favor and go back to the drawing board on this one. It has the word "brittle" written all over it, as you have already found. Instead of building out a batch file to call dtexec, just do it directly either by something like this or this.