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
Related
I have a client that is trying to run the Validate Customer Balances process in accounts receivable and the process does not finish. What tools are available to debug this?
First of all you need to determine whether the process finishes with an error or is simply taking a long time.
This process has a specific warning stating that balance validation takes a long time:
If you see the process progress indicator spinning, it's most likely just taking a long time. In that case you should either wait until the process finishes or follow the warning to select fewer customer.
If the processes finishes with an error indicator:
Open the trace window and run the process again, error details are usually visible in traces. For example, if you see financial period is inactive in traces then you can resolve it by going to the financial period screen and activating it:
Acumatica's T190 Quick Start In Customization and T270 Workflow API documentations describe the Debugging Process while working with Acumatica.
When you install a new Acumatica version, You must put the Install Debugger Tool checkbox.
You must open Visual Studio project as Admin.
To be able to debug the site's original source code, find web.config file of the Acumatica instance. Setting of Vistal Studio also must be changed as described in documentation.
Change the "False" value to "True".
Go to Debug->Attach to Process... or press Ctrl+Alt+P. Search for w3wp.exe, select the instance you needed and Press Attach.
Then put breakpoints and do debugging as you would do in any other project not related to Acumatica.
I find that under certain conditions my signed, inno created installer.exe takes about 10 minutes to open or view properties. When I run as administrator it is immediate, so it seems obvious that the UAC is somehow related. The size of the exe is around 13 MB.
If I copy the file via thumb drive to the target machine, there is no wait. If the same file is downloaded through a browser, there is the 10 minute wait, with explorer going into la la land doing who knows what. After the 10 minute or so wait, the file opens normally with no wait on all subsequent openings.
I am using ksign + commodo to sign the inno exe, and an internal dotnet exe within the inno setup, although I don't think that is a factor.
Windows 10 has the 10 minute wait even running as administrator.
This action is happening for most versions from win 7 on up. There seems to be some change in the exe contents that triggered it, but I haven't found the reason.
Edit 1: I previously contacted ksign, they don't seem to have any issues with my exe, it opens without lag in their environment. This isn't typical however, as many installations face this lag issue. I also tried making some sense out of process monitor monitoring explorer, but there is too much information going on with explorer to pick out the hanging process, unless I a looking in the wrong place.
Edit 2: MsMpEng.exe, which is microsoft security essentials, seems to running amok. This goes on almost endlessly.
Try steps described here: Offline Environment and Authenticode:
To work with UAC-enabled Windows, winsw ships with a digital
signature. This causes Windows to automatically verify this digital
signature when the application is launched (see more
discussions).
This adds some delay to the launch of the service, and more
importantly, it prevents winsw from running in a server that has no
internet connection. This is because a part of the signature
verification involves checking certificate revocation list.
To prevent this problem, create myapp.exe.config in the same
directory as myapp.exe (renamed winsw.exe) and put the following
in it:
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
</configuration>
See KB 936707 for more
details.
Note, this may not work, if your installer already has embedded manifest (more details). In this case you should try to modify your embedded manifest instead.
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.
We have noticed that with the 2012 NetSuite Web services (and perhaps all other versions), when we make a call from a .NET 2.0 64-bit application, if the response does not come back quickly, then intermittently our application will hang however in the NetSuite application logs it appears the SOAP call was successful. The hang eventually times out (timeout) after 5 minutes (!) because NetSuite (or something) keeps the socket open, it just stops sending packets.
We ran a Network Trace and noticed packets coming out of order, being dropped, inexplicable duplicate acks - etc. Essentially, it "freaks out". Microsoft techs have never seen anything like it - least the ones I talked too.
We ran a simple test app that does nothing more than passport in, then do a query for Accounting Periods. It's the search method that hangs as it's parsing the SOAP response - always gets about 10s in.
As soon as we target a 32-bit environment, everything works like a charm, even though the 32-bit binary is running on a 64 bit OS. Clearly, running as a 64-bit app sets some network protocol configuration that NetSuite really doesn't like.
We tested on Azure, Amazon and on a local (to our corporate network) Windows 2008 R2 SP1 64 bit servers - physical and VM's.
We don't have hard evidence of the "why" this is happening, but after a month of pulling our hair out (we're all bald now) we think we've stumbled upon an issue. This one is so weird, however, I'm not willing to go out and claim that it's still not something we're doing. So, if you don't believe:
Open Visual Studio 2010 and create an .NET 2.0 console application targeting "Any CPU".
Do a "Add Web reference..." and add the NetSuite WSDL.
Create a simple passport login and do a search that returns something with some volume.
Run the EXE on a 64-bit OS, several times (this bug is intermittent), during peak working hours (i.e. appears around 7am - 2pm PST).
That's exactly what we did. If you go back and create a new x86 target and rebuild the project, it works fine.
I am facing some critical issue which might be interesting for whom , those who are playing with window azure sdk. I have created on EXE which read performance counter data like CPU, memory, asp.net session from system like
queryCollection = ExecuteWMIQuery("SELECT * FROM win32_perfformatteddata_perfdisk_physicaldisk");
and I have aded this EXE in startup task of simple asp.net application which i have uploaded on window Azure. Now when i connecting to RDP of that I can see following errors in my event log as per below.
Disabled performance counter data collection from the
"ASP.NET_64_2.0.50727" service because the performance counter library
for that service has generated one or more errors. The errors that
forced this action have been written to the application event log.
Correct the errors before enabling the performance counters for this
service.
======================================================================
Windows cannot open the 64-bit extensible counter DLL
ASP.NET_64_2.0.50727 in a 32-bit environment. Contact the file vendor
to obtain a 32-bit version. Alternatively if you are running a 64-bit
native environment, you can open the 64-bit extensible counter DLL by
using the 64-bit version of Performance Monitor. To use this tool,
open the Windows folder, open the System32 folder, and then start
Perfmon.exe.
So i am thinking that my EXE trying to fetch performance counter for 32 bit (win32 indicate that) and that will log above error.
So anyone here came across this type of issue , also if my guess is correct then is there any way to implement my EXE logic such way that it can be run smoothly in any environment(32 or 64 bit)?
Hope that this would remain interesting question here!!!
Thanks In Advance
Arun.
That is correct. IIS running in Azure is running 64-bit unless you change it to run 32-bit in a startup task. You could try building it with the Any CPU setting. But most likely the best way is to do something like what the sysinternal tools does. They will spawn a new process that runs in 64-bit mode when needed. Then you can handle both.
I encountered this error while migrating to a Azure VM.
Solved it by using the InstallUtil which is located in the Framework64 folder instead of the one in the Framework folder