Scheduled Tasks launching apps under svchost using rundll32.exe

 I read your question with interest as I have had numerious problems with Access 2000 and Windows 2003 server, although I call the MSACCESS.EXE directly from the task.   What I see is C000005 errors in task scheduler.  Job runs fine but then hangs at exit.   The other problem I have is that I cannot get any of the jobs to run unless the server is logged in as the user specified in the task.  If not logged in, the jobs simply hang at startup.

  I got around the first problem by enabling Dr. Watson as the default debugger, then setting it so it basically ignored the error without generating any popups.  

  When I bumped into this, I worked on it for several days, trying various methods of launching the Access jobs; directly, from a batch file, used a different scheduler, etc.  But I must admit I never though of calling a shortcut off a menu.  The only advantage I can see from that is getting any command line switches included.

  But overall, I never did find a true fix and came to the conclusion that it was a bug in the MSACCESS.EXE.  Since this was something other then the current release, I highly doubt I'd ever see a fix even if I did report it, so I never bothered.

JimD.  

I wonder if it was flakiness due to memory issues.  There is an MSSQL database (installed by a 3rd party app) on that server and I had other problems this morning - quite different, processes just plain hung or unable to make their connections - because apparently the version of the MSSQL engine this app uses has a memory leak.  After stopping/starting the database, I could get a number of things to function again.  The "private bytes" in use by that MSSQL went from over 800 megs down to around 20 megs...

That doesn't mean it caused the "running under svchost" issue - just that it seems coincidental that the MSSQL memory leak occurred the very next day.

This sounds so familiar, the memory leak that is.  I may have to schedule a regular refresh of the mssql engine.  What a pain in the rear.

I haven't checked on the command-shell close-on-exit thing yet.  I don't know that the scheduled tasks process uses the same command shell instance as running "cmd.exe" from start...run.  It may have its own registry entries, in other words.  I don't know why anyone would change that, but I would like to check.

Does anyone know about settings for the shell instance called by "scheduled tasks?"

Oh, and the C0000005 error using msaccess.exe, and/or the task hanging open - I think that may be the "why" of using the link.  Maybe using the link forces the app to launch using the scheduled task's user credentials in the foreground, or something...  Maybe I'll dig into that a bit, if for no other reason to satisfy my curiosity.  I hate doing things "because that's the way we do it."  There's usually an underlying reason, and if it's a workaround, continuing with the status quo could continue to mask an underlying configuration flaw or the like.  Sometimes it takes a problem like this to actually fix the underlying problem instead of letting the workaround stay in place "because that's the way we do it."

Update:

Still ironing out the kinks.  A big part of the problem was that the DC wasn't starting.  It seemed at first to be resolved by increasing the max RPC endpoints.  I'll dig up the KB article later and post it.  

There were event log entries that pointed to running out of RPC endpoints, but not in so many words.  The failure event log entries made frequent reference to "not enough storage available" - but that's not what it "meant."  It took a lot of digging but it seems that this misleading error message actually indicates a shortage of RPC endpoints.

Even after getting it so the DC would start, there's still some things not behaving normally.  Again, I will post back with more detail later.

Still working on it.  It's a pain.  

Thanks for the continued updates.

JimD

Will get back to it soon.  Need to catch up on other stuff.

C000005 can often be associated with DEP. Have you setup DEP to cover everything, not just Windows processes?

Nope.  DEP is set to default, not everything.

<<C000005 can often be associated with DEP. Have you setup DEP to cover everything, not just Windows processes?>>

  When I was troublshooting my problem, I tried every combination of DEP possible.  No go with any of them.

JimD.