How do I remove GUI.exe

[Allen Drake]

Within the past few days I developed a problem trying to run
Easytune 6. Upon checking for an update and waiting for the file to
download nothing happened so I had to cancel the process. Now I can't
reinstall or remove this PITA pretty much useless app and get a report
every time I boot that says "could not load test file Language.xml".
I am assuming this error is generated from this situation. I then get
a popup that reports "Debug Assertion Failed" relating to GUI.exe
file: wincore.cpp. The advice is to gain information about debugging
Visual C++ documentation on asserts. Short of learning Visual C++ I
have decided that removing this application completely should solve
this problem. Running the uninstall app gets me nowhere as does any of
the attempts from Control Panel.
Can anyone please tell me what has to be done to restore my system?
System Restore doesn't help so before I remove and replace this OS
disk with a clone I am hoping someone here can show me this is not all
that difficult situation.

Thanks.

Al.

 

[Gene E. Bloch]

Within the past few days I developed a problem trying to run
Easytune 6. Upon checking for an update and waiting for the file to
download nothing happened so I had to cancel the process. Now I can't
reinstall or remove this PITA pretty much useless app and get a report
every time I boot that says "could not load test file Language.xml".
I am assuming this error is generated from this situation. I then get
a popup that reports "Debug Assertion Failed" relating to GUI.exe
file: wincore.cpp. The advice is to gain information about debugging
Visual C++ documentation on asserts. Short of learning Visual C++ I
have decided that removing this application completely should solve
this problem. Running the uninstall app gets me nowhere as does any of
the attempts from Control Panel.
Can anyone please tell me what has to be done to restore my system?
System Restore doesn't help so before I remove and replace this OS
disk with a clone I am hoping someone here can show me this is not all
that difficult situation.

Thanks.

Al.

For starters, try finding the files and renaming them as an experiment
in killing them.

I'd search for wincore, not wincore.cpp, since that is not the
executable.

Neither wincore anything nor gui.exe is on this computer, not
surprisingly.

BTW, the way I usually rename executables to lock them out is to change
the extension to xex. Then it's easy to find them again

Somewhere on Microsoft's site are these two free tools:
Autoruns
Process Explorer

They can help you see what tries to start up and what is running.

 

[Paul]

For starters, try finding the files and renaming them as an experiment
in killing them.

I'd search for wincore, not wincore.cpp, since that is not the
executable.

Neither wincore anything nor gui.exe is on this computer, not
surprisingly.

BTW, the way I usually rename executables to lock them out is to change
the extension to xex. Then it's easy to find them again

Somewhere on Microsoft's site are these two free tools:
Autoruns
Process Explorer

They can help you see what tries to start up and what is running.

A debug assert, is an assert statement that's going to trigger a
breakpoint in a debugger like Windbg or equivalent.

The "assert" is in source code module "wincore.cpp". Wincore.cpp
would be one of many files, compiled and linked together to
make GUI.exe.

My guess would be, the code attempts to open "text file Language.xml"
in the install folder, the file is missing, the file opening call
returns an error code, and rather than use a proper error handler,
they check with an "assert", which is silly and sloppy.

Even a junior programmer like me, puts in a check
on the file open line in the code, sees if the status
is good, and then continues on. To use an "assert" to
check for a dynamic condition (one of install files
missing), isn't what you're supposed to do.

Asserts check for things that are known and invariant.
For example, if I know that 2+2 equals 4, and the
computer program at some step should have a value of
4, because I know what the inputs were, I could
check for the value 4 with an assert. If I suspected
a memory error, or a logic error in my program design,
I might use an assert to check for it. It's for
conditions that are *not ever* supposed to happen.

I downloaded the file, the Easytune 6 installer, and it's
20MB. Using 7ZIP, I can see a "setup.exe" type file. But
7ZIP won't show me the files inside. It could be packed
with something. There is no guarantee, if I ran the installer
in a VM, that it wouldn't check for a Gigabyte motherboard
(via an ACPI object in the BIOS), and the installer
would exit before installing anything.

So it needs that file "language.xml" put back to make
it happy.

I would have thought, an uninstaller wouldn't be too
annoyed to have a file like that missing. But it could
be, the same program code that runs the program, is also
being used to uninstall it. And so an attempt to uninstall,
is dying for the same reason the main program path is
dying.

Someone with a Gigabyte motherboard, is going to have
better luck testing that program, than I would. I don't
have any Gigabyte boards here.

*******

Perhaps if you use Process Monitor, and trace file calls,
you can detect the call just before the assert failure,
then put an empty file with that file name in the
stated location.

http://technet.microsoft.com/en-us/sysinternals/bb896645

Or maybe the registry has a path stored in it, to the XML.

Or maybe the actual install folder makes it obvious where
the file belongs. Maybe they'll have better code to handle
malformed input ? Naw...

Paul

 

[Allen Drake]

A debug assert, is an assert statement that's going to trigger a
breakpoint in a debugger like Windbg or equivalent.

The "assert" is in source code module "wincore.cpp". Wincore.cpp
would be one of many files, compiled and linked together to
make GUI.exe.

My guess would be, the code attempts to open "text file Language.xml"
in the install folder, the file is missing, the file opening call
returns an error code, and rather than use a proper error handler,
they check with an "assert", which is silly and sloppy.

Even a junior programmer like me, puts in a check
on the file open line in the code, sees if the status
is good, and then continues on. To use an "assert" to
check for a dynamic condition (one of install files
missing), isn't what you're supposed to do.

Asserts check for things that are known and invariant.
For example, if I know that 2+2 equals 4, and the
computer program at some step should have a value of
4, because I know what the inputs were, I could
check for the value 4 with an assert. If I suspected
a memory error, or a logic error in my program design,
I might use an assert to check for it. It's for
conditions that are *not ever* supposed to happen.

I downloaded the file, the Easytune 6 installer, and it's
20MB. Using 7ZIP, I can see a "setup.exe" type file. But
7ZIP won't show me the files inside. It could be packed
with something. There is no guarantee, if I ran the installer
in a VM, that it wouldn't check for a Gigabyte motherboard
(via an ACPI object in the BIOS), and the installer
would exit before installing anything.

So it needs that file "language.xml" put back to make
it happy.

I would have thought, an uninstaller wouldn't be too
annoyed to have a file like that missing. But it could
be, the same program code that runs the program, is also
being used to uninstall it. And so an attempt to uninstall,
is dying for the same reason the main program path is
dying.

Someone with a Gigabyte motherboard, is going to have
better luck testing that program, than I would. I don't
have any Gigabyte boards here.

*******

Perhaps if you use Process Monitor, and trace file calls,
you can detect the call just before the assert failure,
then put an empty file with that file name in the
stated location.

http://technet.microsoft.com/en-us/sysinternals/bb896645

Or maybe the registry has a path stored in it, to the XML.

Or maybe the actual install folder makes it obvious where
the file belongs. Maybe they'll have better code to handle
malformed input ? Naw...

Paul

Since everything happens before the system is completely booted and I
am able to launch Process Monitor I can't tell exactly what is going
on. This is all caused from Easytune 6 so I renamed the Gigabyte
folder and the reports stop appearing but the application remains. I
guess I can live with that if I have no other options. From what I
have been reading for most of the afternoon there are many others that
are having the same uninstall issues. None with anything that seems to
work for most. I tried safe mode, no luck either.

 

[Gene E. Bloch]

The "assert" is in source code module "wincore.cpp". Wincore.cpp
would be one of many files, compiled and linked together to
make GUI.exe.

My guess would be, the code attempts to open "text file Language.xml"
in the install folder, the file is missing, the file opening call
returns an error code, and rather than use a proper error handler,
they check with an "assert", which is silly and sloppy.

In my experience and practice, and assert will never be triggered unless
there's a bug in the program.

But I wasn't trying to teach programming practice to Allen Drake, I was
trying to help him stop some programs from running.

 

[Gene E. Bloch]

and assert

"an assert"

 

[Paul]

Since everything happens before the system is completely booted and I
am able to launch Process Monitor I can't tell exactly what is going
on. This is all caused from Easytune 6 so I renamed the Gigabyte
folder and the reports stop appearing but the application remains. I
guess I can live with that if I have no other options. From what I
have been reading for most of the afternoon there are many others that
are having the same uninstall issues. None with anything that seems to
work for most. I tried safe mode, no luck either.

This is the verinfo.ini file of the installer (.msi).

[IniVer]
Date=2012/4/24,0
[FileList]
AutoTune.exe=2012/3/9
AODAPI.dll=2009/2/23
AMD8.dll=2010/6/10
amifldrv32.sys=2011/5/5
amifldrv64.sys=2011/5/5
ati64.dll=2007/6/14
aticlocklib.dll=2006/10/4
atidgllk.sys=2006/7/19
atikia64.sys=2006/7/19
atillk64.sys=2006/7/19
atistclk.dll=2006/9/15
AxInterop.ShockwaveFlashObjects_1_0.dll=2000/8/17
bg.dll=2012/2/1
bg.swf=2011/1/26
BC.swf=2012/2/7
bg2.jpg=2012/2/7
CIAMIB.dll=2008/5/7
Chk.exe=2012/3/5
cpu.dll=2012/2/2
DCLib.dll=2011/9/29
default.wav=2012/3/19
device.dll=2010/3/12
et6help.chm=2010/12/2
ET6SC.exe=2012/2/1
ETcall.exe=2012/2/1
et_ycc.dll=200/3/20
GATunner.exe=2012/3/9
GEI.exe=2011/10/27
GPTT.dll=2010/10/19
GService.exe=2010/11/10
GServiceLib.dll=2010/11/3
GUI.exe=2012/1/13
GVTunner.dll=2012/4/2
HardwareHelperLib.dll=2012/2/17
HM.dll=2012/3/1
IccLibDll.dll=2010/6/24
IccProxyLib.dll=2011/12/12
info_I.txt=2012/3/20
Interop.ShockwaveFlashobjects_1_0.dll=2000/8/17
rec.log=2012/2/3
MBG.jpg=2012/2/8
MFCCPU.dll=2012/4/2
MFCET.dll=2012/4/17
MFCSPD.dll=2011/12/27
Normal.dll=2012/4/24
Nvgpio1.dll=2005/9/9
OCK.dll=2012/4/18
OCK_IV.dll=2012/4/10
ParsBIOS.dll=2011/10/11
platform.dll=2010/3/12
RA.swf=2012/2/6
Run.exe=2012/3/5
SCEWIN.exe=2011/5/5
SCEWIN_64.exe=2011/5/5
SetDev.exe=2012/2/22
SetupICCS.exe=2011/9/1
SF.dll=2011/12/6
Sh_bg.jpg=2012/2/7
StablityLib.dll=2011/3/1
Stress.exe=2012/2/3
STT.dll=2011/10/18
work.dll=2012/4/23
ycc.dll=2011/9/14
Language\English\string.xml=2012/3/20
Language\Traditional Chinese\string.xml=2012/3/20
Language\Simple Chinese\string.xml=2012/3/20
amd64\AODDriver.sys=2010/3/12
i386\AODDriver.sys=2010/3/12
AOD7\amd64\AODDriver.sys=2009/2/23
AOD7\i386\AODDriver.sys=2009/2/23
AOD8\amd64\AODDriver.sys=2010/3/12
AOD8\i386\AODDriver.sys=2010/3/12
DLLS\install_flash_player_11_active_x_32bit.exe=2011/11/10
DLLS\install_flash_player_11_active_x_64bit.exe=2011/11/10
DLLS\PowerControl.dll=2010/5/18
DLLS\rec_def.log=2012/2/3

There's no "Language.xml" in there. The closest entry functionally
is "Language\English\string.xml". Perhaps that file gets copied somewhere
where the installed tool can find it (after the installer discovers
whether the computer is Chinese or English).

The gui.exe file is 219,760 bytes. And it appears to be packed
with Armadillo as well, so I can't scroll through with a hex
editor looking for text strings.

I think it's likely it is launching a service just after bootup,
and that would check for updates. I see the "GService.exe" thing,
so that might be part of getting updates. The updates might even
have left a temporary folder in %temp% so have a look in there
and see what's up.

*******

What I've got there, is an MSI file. I can't really tell what the
file manifest would be, of the files actually installed. The way
I got it to run, it would not run to completion and the installer
backed out the changes. All I got, was the MSI file to look at.
Which was in my %temp%. So still not much closer. Maybe the XML
file is stored in an AppData folder somewhere.

Paul

 

[Paul in Houston TX]

Allen Drake wrote:
(snip) >

Since everything happens before the system is completely booted and I
am able to launch Process Monitor I can't tell exactly what is going
on. This is all caused from Easytune 6 so I renamed the Gigabyte
folder and the reports stop appearing but the application remains. I
guess I can live with that if I have no other options. From what I
have been reading for most of the afternoon there are many others that
are having the same uninstall issues. None with anything that seems to
work for most. I tried safe mode, no luck either.

IMO and my experience, ET6 is a very buggy program. It works on
this xp machine, it caused me to reinstall win7 on the
gamer machine, it messed up my last xp machine and I had to
reinstall xp. The ET6 online upgrades have never worked for me.
The upgrades seem to be bad. It simply won't work on my
son's 2011 cpu machine.

 

[Paul]

In my experience and practice, and assert will never be triggered unless
there's a bug in the program.

But I wasn't trying to teach programming practice to Allen Drake, I was
trying to help him stop some programs from running.

Well, my comment was to point out, that a "finished" program,
shouldn't be throwing asserts at users.

What was done here, was an abuse of an assert. Files come and
go, and if a file is missing, should be handled with a dialog
box, and a suggestion as to how to repair it. Like "put back
my configuration file, you oaf" or something similarly friendly

For examples of helpful dialogs, I recommend reviewing the
dialogs provided by the "Imgburn" program. Always good for a
laugh, as well as the loud sound effects used when the program
is finished. That's an example of some over-the-top programming.
At least I haven't seen any "asserts" leak out of that program.
Every event is handled sarcastically and with precision.

Paul

 

[Allen Drake]

*******

What I've got there, is an MSI file. I can't really tell what the
file manifest would be, of the files actually installed. The way
I got it to run, it would not run to completion and the installer
backed out the changes. All I got, was the MSI file to look at.
Which was in my %temp%. So still not much closer. Maybe the XML
file is stored in an AppData folder somewhere.

Paul

I guess for now everything is going to stay the way it is with the
remnants of this application considered junk. I get no more popup
warnings and see no ill effects after renaming the folder in Program
Files(x86) to "GIGABYTEold".

 

[Allen Drake]

Allen Drake wrote:
(snip) >
IMO and my experience, ET6 is a very buggy program. It works on
this xp machine, it caused me to reinstall win7 on the
gamer machine, it messed up my last xp machine and I had to
reinstall xp. The ET6 online upgrades have never worked for me.
The upgrades seem to be bad. It simply won't work on my
son's 2011 cpu machine.

I've had it on at least one system for quite some time and never saw
any problem. I remember ver.5 got updated to 6 some time ago. I
considered it an app like the ones Intel includes on their MoBo disks
and was nothing to worry about. I'll be thinking twice from now on.

 

[Gene E. Bloch]

Well, my comment was to point out, that a "finished" program,
shouldn't be throwing asserts at users.

Yes - the bug got out of the cage

Ideally, it would have been noted during thorough testing at the factory
and fixed before it went public

 

[Paul]

Yes - the bug got out of the cage

Ideally, it would have been noted during thorough testing at the factory
and fixed before it went public

Um, that's worse than a bug.

That's a homegrown programming style.

What's needed is a "code review" by real programmers.
To help that developer out.

The Test group or QA, isn't there to help with staffing problems.

Paul

 

[Jason]

Within the past few days I developed a problem trying to run
Easytune 6. Upon checking for an update and waiting for the file to
download nothing happened so I had to cancel the process. Now I can't
reinstall or remove this PITA pretty much useless app and get a report
every time I boot that says "could not load test file Language.xml".
I am assuming this error is generated from this situation. I then get
a popup that reports "Debug Assertion Failed" relating to GUI.exe
file: wincore.cpp. The advice is to gain information about debugging
Visual C++ documentation on asserts. Short of learning Visual C++ I
have decided that removing this application completely should solve
this problem. Running the uninstall app gets me nowhere as does any of
the attempts from Control Panel.
Can anyone please tell me what has to be done to restore my system?
System Restore doesn't help so before I remove and replace this OS
disk with a clone I am hoping someone here can show me this is not all
that difficult situation.

Thanks.

Al.

You might try simply re-installing the app to see if you can then
uninstall it. The Revo uninstaller is a genius at this sort of thing;
there's a free version you can try.

Jason