Ghost Buttons -how do I kill them?
 

You know when you open a program, a button appears on the task bar...then when you close the program, the button disappears... Well, for the first time, the button does not disappear.

I have had this one annoying button sitting there for a few days, with no identifying feature as to which prog it is related to ...it is just a light blue [in contrast to the darker task bar] button with a small dos window as the identifying icon in its usual place to the left of the button ...which usually means XP cannot associate a program with the button...there for no "hook."

I have done all of the obvious things, as far as I can tell, such as:

I have shut down system restore to clean out the restore points.
I have scanned for any malware, etc..
I have down the usual maintenence, as I am an old hand at maintenance.
I have scanned the registry for any reference to the task bar that might give me a hint re: where to start...but nothing seems to be available.

ANY SUGGESTIONS?

Edited: 07-23-07...SOLVED...go to last post

Hello, go to this page: http://www.microsoft.com/technet/sys...***plorer.mspx and download procexp.

Run the program, go to view and select 'view lower pane' and choose the 'view dlls' option.

In the top pane, select explorer.exe and all the dlls being used within explorer will be shown in the lower pane.

It will probably take a while, but work through the list in the bottom pane until you find one that is running in relation to one of the programs you use.

When you think that you have found it, take note of the name, right click and choose either properties and look through them, or search online which should tell you what program uses it.

Also, you can use resource hacker which is a handy freeware tool. It will allow you to view the icons being used by any dll.

There are several places where you can find it e.g.
:Resource Hacker

If you need any help with using either program, let me know

Regards

Martin

Part way there...Step 1, done...
 

Thanks for the reply...

I fired up Process Explorer, and did what you said...but that, for me was a useless exercise... with about 50 dlls facing me, isolating the culprit would be too daunting.

I would think that you would need to know the prog that you used to activate specific dlls in order to ferret out those dlls to then deal with them. I indicated before that I did know what program was used. About 90% of them were MS dlls, so that did not help. The other 10% were for running progs. There were none that were associated with a non-running program. The few that were unassociated, and which I killed, had no effect.

While in Process Explorer, I mosied on up to explorer.exe and debugged it, off the right mouse toggle... To my surprise, that worked for session that I am on, but upon reboot, I am back where I started. I might add, that Dr. Watson briefly showed his face, but quickly disappeared without so much as a howdy doody...so where did the bug-log go? Now, this was a new discovery for me...so I think that I am half way there.

I would think that the next step would be to track down in the registry where explorer.exe hides, and hides its taskbar functionary buttons. There has to be a residual ghost lurking about somewhere to trigger the appearance of the button.

"debugging" cleans it off the active taskbar, but not completely out of the system shell commands, it appears...

Step 2 ???

1. Find the Dr. Watson bug log...
2. Find the other half of solution...wipe it from whichever memory bank it is hiding in, thus triggering the reactivation...

There might be more steps that I am not aware of yet...bummer

I know it looks a bit daunting, but I'm sure you already know that a lot of problems get solved through the process of elimination.

Your Dr.Watson log is called Drwtsn32.log, if you go to your system32 folder and execute Dr.Watson, you should get a report on any errors.

The .dll is attempting to place an icon in your notification area and will be listed in the bottom pane under explorer.exe in prcoexp, so we know that it is definitely one of them!
(This can be very useful in finding strings in some of those annoying virus pop-ups: Right-click the suspect .dll> go to properties> select the strings tab> check the memory button> and search for the text in the 'pop-up').

However it is obviously broken somewhere along the line, run a disk check on your next re-boot. Check your start-up programs and take note of them to see if something on the list isn't starting.

When you run the debugger, it is noticing the problem and just killing it, which is why the mystery icon disappeared.

If you need to check your settings for Dr.Watson, try the microsoft support site: Microsoft Windows XP - Using the Dr. Watson log file. Like you say, a bit daunting but I'm afraid you've started something!!!!

And this one helps you with interpreting the log file: Microsoft Corporation

Do any balloon tips come up when you hover over it?

You can also try a registry cleaner.

Regards

Martin

I am finding your responses very illuminating. I hope that you do not get frustrated and bail out... ;)

All programs are working properly. I have only a few in the startup folder and all of them are up and running correctly. So it must be something in the background that is not serious to the operating of the computer, but serious enough to be an annoyance... I may be off base, but I have a gut feeling that it is a "cleanup" issue... something is not getting the message that the prog has gone on to another task, and a footprint is left on the task bar.

I have a wee prog called StopIt by MacDevelopment [ http://www.McDev.com ] It identified two instance of explorer.exe running at the same time. I killed one, the task bar disappeared and did not return. I went to StopIt again, and the second instance was still there, but no task bar. I killed it too. I returned to Task Manager and fired up explorer.exe again, and then returned to StopIt. Neither the ghost image was there, nor was the extra version of explorer.exe This seemed to accomplish the same end as the debugging of explorer.exe in Process Explorer.

I am going to delete my system restore points again. It did not work to eliminate the return of it last time...and reboot. I'll return here in a bit, to edit this note with what happened.

In the meantime, here is some other reading as to what was previously done so I don't lose that info.

The Dr. was brought into the discussion but it provided no opportunity to do anything with it...no command options to have it produce anything.

I went to the *.log file and opened it up... there did not seem to be any pattern as to a particular "program" but there seemed to be a consistent complaint:

"WARNING: Stack unwind information not available. Following frames may be wrong. *** ERROR: Symbol file could not be found. Defaulted to export symbols for c:\windows\srchasst\srchui.dll - "

The *.dll reference was different each time, but the warning and error seemed to be the same... I suppose that I will need to direct whatever to the Symbol file. I did download the symbols for the debugger some time back, but did not know what to do with them. Should I go someplace in the register to enter a command to go someplace to find them...and do I need to do much with the folder in which the file is?

Here is an example of the last complaint in Dr. Watson's log... I checked out your MS reference which was supposed to assist in the translation but it was no help, because what it described, did not appear to be here... Nor, does it plainly describe where one problem's record starts and stops and another starts and stops...

e.g.


*----> State Dump for Thread Id 0x638 <----*

eax=00000000 ebx=020efec0 ecx=00000002 edx=00000002 esi=00000104 edi=00d2e724
eip=79004c44 esp=00d2e2ac ebp=00d2e338 iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246

*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\mscoree.dll -
function: mscoree!CreateConfigStream
79004c2b 00538b add [ebx-0x75],dl
79004c2e 9d popfd
79004c2f a801 test al,0x1
79004c31 0000 add [eax],al
79004c33 56 push esi
79004c34 57 push edi
79004c35 8bbdac010000 mov edi,[ebp+0x1ac]
79004c3b 894580 mov [ebp-0x80],eax
79004c3e 895d88 mov [ebp-0x78],ebx
79004c41 8d4802 lea ecx,[eax+0x2]
FAULT ->79004c44 668b10 mov dx,[eax] ds:0023:00000000=????
79004c47 40 inc eax
79004c48 40 inc eax
79004c49 6685d2 test dx,dx
79004c4c 75f6 jnz mscoree!CreateConfigStream+0x5f3 (79004c44)
79004c4e 2bc1 sub eax,ecx
79004c50 d1f8 sar eax,1
79004c52 8bf0 mov esi,eax
79004c54 8bc3 mov eax,ebx
79004c56 8d4802 lea ecx,[eax+0x2]
79004c59 668b10 mov dx,[eax]

*----> Stack Back Trace <----*
WARNING: Stack unwind information not available. Following frames may be wrong.
ChildEBP RetAddr Args to Child
00d2e338 77dd6fbf 00d2e450 00000aa6 00d2e448 mscoree!CreateConfigStream+0x5f3
00000000 00000000 00000000 00000000 00000000 ADVAPI32!RegCloseKey+0x3cf

*----> Raw Stack Dump <----*
0000000000d2e2ac c0 fe 0e 02 04 01 00 00 - 00 00 00 00 00 00 00 00 ................
0000000000d2e2bc 00 00 00 00 c0 fe 0e 02 - a2 3b 00 79 35 00 38 00 .........;.y5.8.
0000000000d2e2cc 42 00 43 00 37 00 44 00 - 34 00 33 00 7d 00 5c 00 B.C.7.D.4.3.}.\.
0000000000d2e2dc 49 00 6e 00 70 00 72 00 - 6f 00 63 00 53 00 65 00 I.n.p.r.o.c.S.e.
0000000000d2e2ec 2c e4 d2 00 fe e1 90 7c - 6c e3 d2 00 28 e3 d2 00 ,......|l...(...
0000000000d2e2fc 6c fb 90 7c 71 fb 90 7c - 6c e3 d2 00 fe e1 90 7c l..|q..|l......|
0000000000d2e30c 2c e4 d2 00 04 e3 d2 00 - 0a e2 90 7c 08 ea d2 00 ,..........|....
0000000000d2e31c 18 ee 90 7c 78 fb 90 7c - ff ff ff ff 71 fb 90 7c ...|x..|....q..|
0000000000d2e32c b4 6f dd 77 00 00 00 00 - 00 00 00 00 00 00 00 00 .o.w............
0000000000d2e33c bf 6f dd 77 50 e4 d2 00 - a6 0a 00 00 48 e4 d2 00 .o.wP.......H...
0000000000d2e34c 40 e4 d2 00 a6 0a 00 00 - 00 00 00 00 6c e3 d2 00 @...........l...
0000000000d2e35c 0e 00 00 00 a6 0a 00 00 - 74 e3 d2 00 00 00 00 00 ........t.......
0000000000d2e36c c8 05 91 7c 00 30 12 00 - 40 e4 d2 00 51 05 91 7c ...|[email protected]..|
0000000000d2e37c e8 15 09 00 6d 05 91 7c - 04 61 e4 77 00 61 e4 77 ....m..|.a.w.a.w
0000000000d2e38c 00 00 00 00 c0 e3 d2 00 - 3d fb 90 7c 50 e4 d2 00 ........=..|P...
0000000000d2e39c 00 00 00 00 08 00 00 00 - 6c fb 90 7c 71 fb 90 7c ........l..|q..|
0000000000d2e3ac 00 00 00 00 50 e4 d2 00 - 3d fb 90 7c ac e3 d2 00 ....P...=..|....
0000000000d2e3bc 89 8b 00 00 18 e4 d2 00 - 18 ee 90 7c 78 fb 90 7c ...........|x..|
0000000000d2e3cc ff ff ff ff 00 00 00 00 - fd 51 89 09 1c e4 d2 00 .........Q......
0000000000d2e3dc 7d d7 02 79 90 02 00 00 - d4 57 02 79 00 00 00 00 }..y.....W.y....

To configure your symbols in procexp or Windows Debugger go to the appropriate menu, 'Configure Symbols' and copy and paste this line: srv*c:\symbols*Symbol information.

If you want to use Dr.Watson as your default debugger, go to this link, it explains how to correctly install the symbols you downloaded from Microsoft: Set up Dr. Watson for quality system debugging.

Can you confirm that you have run a disc check and a virus/spyware scan in safe mode ( also check if the second instance of explorer.exe is running under safe mode ).

Configure your symbols, and then re-boot and if it's possible, attach the full Dr.Watson log and I'll give you a hand to interpret it.

From what I can see in your post there is a reference in the Raw Stack Dump to an InprocServer32 folder in the registry which could help us find the culprit as it usually contains a reference to the .dll being used and having the symbols correctly configured may show the correct values.

If you work your way around the Microsoft Link in the previous post you should be able to find some references to registry entry settings for either Dr.Watson or you chosen default debugger.

Regards

Martin

Solution appears to be holding...ran check disk
 

Running check disk seemed to solve the problem.

Thank you so very much for having taken the time to advise. It appears that the check disk command worked. It will take a while to fathom your other suggestions, which I shall mull over in due course.

On previous occasions, I watched the systray carefully, and the offending bug seemed to load at the same particular time in the sequence of other progs that I have loaded to that effect. There was a logic to the sequence, which leads me to believe, that "somewhere" in the registry there is a purposeful key organizing this loading sequence.

Therefore, where in the registry, is the list of commands and paths advising explorer to load certain start up programs, and in which order? One should be able to "visit" that location and note which progs are in the "train" and then be able to zap the offending ones, in order...and via the process of elimination, isolate the offending program.

This may be a faster method than trying to second guess the dll issue. I had 98 MS dills active at the time, along with about 25 "others." And everything was working fine...save for that ghost!

P/S ... I use "RestoreIT" which I highly recommend. I totally deleted it from my system, before rebooting and after again debugging in Process Explorer, just in case it was the culprit for continuing to "renew" my bug issue upon every reboot.

Thanks again...

So far so good
 

Seems to be holding...

Thanks again, for leading me to the well ;)

Now, to reinstall RestoreIT ;)

No problem, there's method in my madness ( so the saying goes )

There is another program made by the same people that made procexp, which will help with the start-up sequence yoou mentioned: Download Autoruns 8.70 - filehippo.com

Regards

Martin

Forgot about that...
 

Thanks for the reminder...I had that prog and forgot to use it. I was so wrapt up in the issue, and what I figured was the "real" solution, that I forgot about the tools I have already...problem is, I've got too many to remember ;)

Be that as it may, again, I think I solved the problem. It appears that my logic was not too far off base.

No sooner had I "solved" the problem prior to my previous post, then it was back, on another reboot. So, my excitement was short lived.

As I referred to a "sequencing" suspicion in my last post...I persistently followed up on that by "observing" about 5 reboots and paid particular attention to the exact time the spectre appeared on the task bar. It was closely associated in time, to a particular desk top calendar...when the calendar appeared on the desktop, the ghost appeared in the task bar.

So, I began mucking about with it...and found that it would not respond to certain commands which told me that something was amiss. So, I reloaded the program, and the ghost disappeared on the next reboot.

I am holding my breath. If I don't return, you will know that I was successful.

So, what have I done...for our readers...various successful and then unsuccessful runs...

1. defrag ...did not work
2. debugged explorer.exe via Process Explorer ... tap on explorer.exe in Process Explorer with right mouse button and then go down to "debug" ...built into the shell ...worked, but not on a reboot
3. check disk ...worked, but not on a reboot
4. cleaned registry a few times with different programs in effort to repair file/path links ...did not work
5. *** reloaded program ...worked but have not rebooted to make sure it will hold...
6. cleaned registry again, and established new restore point
7. prayed ;)
8. crossed fingers ;)
9. shut down... will get back to you...

Editing: Rebooted and no more ghosts on task bar... It appears that by re-loading the program, the "missing link" was rebuilt.

Time will tell...:0

Editing: Sunday 07-15-07 > still working... So, I am going to assume that reloading the program, which I finally isolated, worked. For those of you have a program, including myself, on future occasions, we are going to need better luck to identify the offending dll, or file that had its link[s] broken. And a better/more efficient way of finding broken links exhibiting ghost issues. AND we are going to need to know where in the registry the setup/run files are located to determine the sequence they load in, on startup. It is not enough to know where the "Run" folder is located... in my case nothing was in those folders... It must be somewhere else in memory...but where?