PFSullivan
asked on
Error - "Could not locate inf file Au_gdi.inf"
Hi Experts - I can't seem to locate any info on this error
"Could not locate inf file Au_gdi.inf
I have- 34 (Win 2K) systems on one network all get this error on boot. Any ideas?
I'm on site
Thanks, Pat
"Could not locate inf file Au_gdi.inf
I have- 34 (Win 2K) systems on one network all get this error on boot. Any ideas?
I'm on site
Thanks, Pat
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Sounds like your explorer might have gotten hijacked.
I would run a spyware finder (adaware, spybot s&d, etc) and see what it turns up.
Jared
I would run a spyware finder (adaware, spybot s&d, etc) and see what it turns up.
Jared
ASKER
Jared - Hi - I followed your advice and ran SpyBpt S&D and Hijackthis on one of the affected systems
Spybot found a DSO Exploit and nothing else.
The Hijackthis showed nothing that I did not recognize. These stations are used as "Call Center" terminals and consequently are on the web all day.
While this error appears on boot, it does not seem to be causing any other problems.
Do you agree with moorhouselondon that deleting the registry entry would be a good idea?
Thanks, Pat
Spybot found a DSO Exploit and nothing else.
The Hijackthis showed nothing that I did not recognize. These stations are used as "Call Center" terminals and consequently are on the web all day.
While this error appears on boot, it does not seem to be causing any other problems.
Do you agree with moorhouselondon that deleting the registry entry would be a good idea?
Thanks, Pat
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
You're a braver soul than I - Thanks- I'll try it on a couple and see what I get.
regards, Pat
regards, Pat
'ang about. The registry entry is not in the same place that I thought it would be, so be careful! Deleting this in the position it is, under CurrentUser is probably ok, but it has a different function than my initial thoughts.
This is due to a windowsupdate detection tool "Microsoft GDI+" (KB873374) (I suppose you are using a SUS server or an windowsupdate auto installation even when users are logged in) that just detect if you have the following programs and open a webpage concerning security on them :
Microsoft .NET Framework 1.1
Microsoft .NET Framework 1.0
Microsoft Digital Image Suite 9
Microsoft Digital Image Pro 9
Microsoft Greetings 2002 1.0
Microsoft Office 2003, All Editions
Microsoft Office XP, All Editions
Microsoft Office 2000, All Editions
Microsoft Picture It! Digital Image Pro version 7
Microsoft Picture It! Photo 2002
Microsoft Picture It! Photo Premium 2002, version 1.0
Microsoft Picture It! Publishing Platinum 2002 1.0
Microsoft Picture It! Publishing 2002
Microsoft Picture It! Photo Premium 9
Microsoft Picture It! Photo Premium version 7
Microsoft Picture It! Photo version 7
Picture It! on MSN
Microsoft Visual Studio .NET (2003), Academic Edition
Microsoft Visual Studio .NET (2003), Enterprise Architect Edition
Microsoft Visual Studio .NET (2003), Enterprise Developer Edition
Microsoft Visual Studio .NET (2003), Professional Edition
Microsoft Visual Studio .NET (2002), Academic Edition
Microsoft Visual Studio .NET (2002), Enterprise Architect Edition
Microsoft Visual Studio .NET (2002), Enterprise Developer Edition
Microsoft Visual Studio .NET (2002), Professional Edition
more info on http://support.microsoft.com/default.aspx?scid=kb;en-us;873374
The problem is that the system was waiting for a login in a administrative rights sessions to complete the proper installation of the patch, and I'm quite sure that the first opened session was made by a regular user, no?
If you don't need that detection, you can remove the line in the HKLM/.../RUNONCE key, manually or with a script that can deploy it to all your clients remotely. Contact me if you need to do it I'll send you my script.
Cheers
Microsoft .NET Framework 1.1
Microsoft .NET Framework 1.0
Microsoft Digital Image Suite 9
Microsoft Digital Image Pro 9
Microsoft Greetings 2002 1.0
Microsoft Office 2003, All Editions
Microsoft Office XP, All Editions
Microsoft Office 2000, All Editions
Microsoft Picture It! Digital Image Pro version 7
Microsoft Picture It! Photo 2002
Microsoft Picture It! Photo Premium 2002, version 1.0
Microsoft Picture It! Publishing Platinum 2002 1.0
Microsoft Picture It! Publishing 2002
Microsoft Picture It! Photo Premium 9
Microsoft Picture It! Photo Premium version 7
Microsoft Picture It! Photo version 7
Picture It! on MSN
Microsoft Visual Studio .NET (2003), Academic Edition
Microsoft Visual Studio .NET (2003), Enterprise Architect Edition
Microsoft Visual Studio .NET (2003), Enterprise Developer Edition
Microsoft Visual Studio .NET (2003), Professional Edition
Microsoft Visual Studio .NET (2002), Academic Edition
Microsoft Visual Studio .NET (2002), Enterprise Architect Edition
Microsoft Visual Studio .NET (2002), Enterprise Developer Edition
Microsoft Visual Studio .NET (2002), Professional Edition
more info on http://support.microsoft.com/default.aspx?scid=kb;en-us;873374
The problem is that the system was waiting for a login in a administrative rights sessions to complete the proper installation of the patch, and I'm quite sure that the first opened session was made by a regular user, no?
If you don't need that detection, you can remove the line in the HKLM/.../RUNONCE key, manually or with a script that can deploy it to all your clients remotely. Contact me if you need to do it I'll send you my script.
Cheers
Cervomix; could you send me the script, or post it on this website, we have the same problem with several users. Thx jcorzatt@yahoo.com
OK, here's the .VBS script that work with arguments if you're not in a MS domain, note that the user logged on the remote computers must have "user with power rights" group rights (means they can modify registry keys & values), else if they're just "user" you'll have to modify yourself that script:
const HKEY_LOCAL_MACHINE = &H80000002
Set objArgs = WScript.Arguments
For Each strArg in objArgs
strComputer = strArg
Set oReg=GetObject("winmgmts:{ impersonat ionLevel=i mpersonate }!\\" &_
strComputer & "\root\default:StdRegProv" )
strKeyPath = "SOFTWARE\Microsoft\Window s\Currentv ersion\Run Once"
strStringValueName = "GDI Detect Tool.."
oReg.DeleteValue HKEY_LOCAL_MACHINE,strKeyP ath,strStr ingValueNa me
Next
To make it work, create a txt file, name it like you want (ie: removeAU_gdi.vbs) and paste the above in it. launch it from command line with names of your computers as arguments (ie: removeAU_gdi.vbs computer1 computer2 computer3). You can also modify this script so as it uses a .txt file with computers names in it.
Here is the "local" version for a single PC (I think it can be used too to deploy it on MS domain clients).
const HKEY_LOCAL_MACHINE = &H80000002
strComputer = "."
Set oReg=GetObject("winmgmts:{ impersonat ionLevel=i mpersonate }!\\" &_
strComputer & "\root\default:StdRegProv" )
strKeyPath = "SOFTWARE\Microsoft\Window s\Currentv ersion\Run Once"
strStringValueName = "GDI Detect Tool.."
oReg.DeleteValue HKEY_LOCAL_MACHINE,strKeyP ath,strStr ingValueNa me
I hope it'll be useful.
Cheers
const HKEY_LOCAL_MACHINE = &H80000002
Set objArgs = WScript.Arguments
For Each strArg in objArgs
strComputer = strArg
Set oReg=GetObject("winmgmts:{
strComputer & "\root\default:StdRegProv"
strKeyPath = "SOFTWARE\Microsoft\Window
strStringValueName = "GDI Detect Tool.."
oReg.DeleteValue HKEY_LOCAL_MACHINE,strKeyP
Next
To make it work, create a txt file, name it like you want (ie: removeAU_gdi.vbs) and paste the above in it. launch it from command line with names of your computers as arguments (ie: removeAU_gdi.vbs computer1 computer2 computer3). You can also modify this script so as it uses a .txt file with computers names in it.
Here is the "local" version for a single PC (I think it can be used too to deploy it on MS domain clients).
const HKEY_LOCAL_MACHINE = &H80000002
strComputer = "."
Set oReg=GetObject("winmgmts:{
strComputer & "\root\default:StdRegProv"
strKeyPath = "SOFTWARE\Microsoft\Window
strStringValueName = "GDI Detect Tool.."
oReg.DeleteValue HKEY_LOCAL_MACHINE,strKeyP
I hope it'll be useful.
Cheers
ASKER
Thanks Cervomix - I'll be on that site again on Wed. and I'll try your script - The stations where I deleted the registry entry have not had any problems.
Pat
Pat
Concerning my last post I forgot to say that you must be logged as administrator on the computer where you launch the remote execution script, and that the pc clients must have the same administrator login and password in their SAM (whatever the user and its privileges who is currently logged in).
I Hope my english is understandable enough! :)
I Hope my english is understandable enough! :)
Dear all experts,
currently I am facing this problems for few clients when they login, especially if the user doesnt have the administrator rights ...
I will appreaciate if anyone can help pls
Hoay Fern
currently I am facing this problems for few clients when they login, especially if the user doesnt have the administrator rights ...
I will appreaciate if anyone can help pls
Hoay Fern
I know exactly what this issue is, it's something that has come down through Windows updates (or automatic updates, hence the "au" part of the message). What you may want to do, if possible, is run a System Restore (if you're set up for them) to maybe the day before these errors came up due to the update that was sent out. After that you may want to go out to WindowsUpdates. com and manually install the latest updates to the PC. You can also disable the automatic updates service on the machine and reboot. The error won't come back then. You can try re-enabling the service, rebooting again, and seeing if the error returns.
Hacking the registry will get rid of the error which is happening because the file was deleted.
If you investigate you will probably find that your anti-virus program turned up a (?false?) positive and quarantined the file.
Since it is happening to every system on the network that is even more likely. It is also pretty certain that this file/program is part of your "standard build."
If you investigate you will probably find that your anti-virus program turned up a (?false?) positive and quarantined the file.
Since it is happening to every system on the network that is even more likely. It is also pretty certain that this file/program is part of your "standard build."
I had this, and just had to log in as Administrator...
when the end-user logged in after that, the message was gone.
when the end-user logged in after that, the message was gone.
Now that bmirza mentioned logging on as Administrator, I realized that this happened with one of my computers as well. I logged on as the local restricted account and saw the message, then logged on as Administrator to install an update. I noticed later that the error was no longer showing up.
ASKER
CurrentUser\Software\Micro
Before I get crazy and delete the entry, have you any idea what this is controlling?
Thanks, Pat