Installing ATI Catalyst Control Center causes File System Object to stop functioning?

I know that this is a weird problem, so any ideas are appreciated.

I have several scripts that automatically run in succession on newly-deployed systems.  They do things like copy files and install software such as the SMS client.  It had been working fine for the longest time.

Suddenly, something has changed and now things are not happening as they should.  The first several scripts still run fine.  The problem is in the last 2-3 scripts.  Files and folders don't copy.  Logging to text files does not happen; they are not even created.  There are no error messages.  It is as if the commands are ignored.  The scripts work just fine if run manually.  It seems to be limited to only the file system object because actions performed by the shell object still work, such as running a program.

I have narrowed the problem down to the script which installs the ATI Catalyst Control Center.  If I remove the script, then everything starts working again.  When I put it back, things are broken again.  I may contact ATI support, but in the past they have been useless on issues directly related to their product, so I don't expect much help on something as obscure as this.

Could the ATI installer be replacing some file(s) related to the file system object?  I have checked scrrun.dll before and after the ATI installer and it is not changed.  Are there other files to check?

Again I know this is a pretty weird problem, but I really appreciate any help or ideas you can give.

Does the problem happen whether or not you install ATI Catalyst Control Center within a script?

Well, even if I run the script manually then it works.

To explain what I mean, normally the scripts are kicked off via the Windows RunOnce reg key.  If I interrupt that and run them manually one at a time, then I don't see the problem.

Obviously when they run via the RunOnce key the Windows shell is not running, but when I run them manually it is.  I wonder if that could have an impact somehow.

I would imagine that it has an impact. RunOnce keys are probably being run under the system service account but I am not 100% positive that is the case.

ebgreen


I would imagine that it has an impact. RunOnce keys are probably being run under the system service account but I am not 100% positive that is the case.

Good thought, but I checked and it is not System.  It is running as built-in administrator.

A while ago, I encountered a strange issue where during my PC setup script, while installing the Intel Chipset my script would just quit, no error no message of any sort.  This was just a simple script that would call a script stored on our network.  No amount of tweaking the local script would work.  What I ended up doing was creating an autoIT script whose only function was to call that local script.  Once I did that, I never had an issue with my local script dieing.  I can't remember if I tried a CMD or BAT file, but that maybe an option.

I have one more clue.  I ran Process Monitor from the Sysinternals Suite.  It shows an error 0xC000023C when the problem scripts are accessed.  Google reveals that this error is a Windows standard error code for network unreachable. 

The other interesting thing Process Monitor shows is this: up to the point where everything is working, scripts are called via UNC path.  Once the problem begins, they are called by a mapped drive.