quote:
[i]Originally posted by Mike Singer[/i]
[b]rseiler[/b], please e-mail a screenshot of the GPF error message to me at [[email protected]][email protected][/email].
It bounced:
Final-Recipient: rfc822; [email protected]
Action: failed
Status: 5.0.0 [email protected]
Diagnostic-Code: smtp; Permanent Failure: Other undefined Status
Last-Attempt-Date: Fri, 14 Jan 2005 23:57:48 -0000
Ed, we’re several levels of miscommunication deep now, so I’ll try to keep this extremely short so that this thread is back on track. I should emphasize at the top that what I do or do not have integrated in the shell is n/a to all this.
-I’m using the terms Explorer and Windows Explorer and Shell synonymously. I don’t think you are.
-It’s extremely common for an app to hook into Explorer for convenience sake, and half the time you don’t even have a choice not to do that. Examples of its use: Right-click on a group of files, select “Add to archive” (or whatever) and it calls your archiver to zip them. Select another group and have your AV called to scan them. Etc. That your system has not a single one of these (check again) suggests to me that you either installed fresh yesterday or haven’t installed more than one or two apps.
-The statement “But I have no files on my Desktop, only shortcuts” mystifies me. Nothing in this entire thread pertains to what is or is not on the Desktop.
-“They’re written in Visual Basic, and an older version if I’m not mistaken.” No and no. First, the version of the DLL is n/a, since I can place the old version in the WW directory (which it uses, as evidenced by data in the error report), and it makes no difference. Second, the apps I was questioning – such as OE – are NOT written in VB at all, let alone an old version. I questioned, then, why they were using the DLL on this particular system but not on others, and further speculated how that might be related to the problem.
-And no, I did not “select the option to have a VB app linked to OE during it’s install” for any of these apps that are using the DLL – they’re not even VB apps. Outlook?! OE?! No. I don’t think that any of them (listed in early posts) are. Further, none of the apps that ARE hooked into the shell (like WinRAR) use the DLL…one of the main reasons all this talk of the shell AFAIK has nothing to do with the problem and is only confusing the issue.
-Renaming DLL’s (or deleting them) simply causes XP to automatically restore them the next time an app calls to use it. There are ways around that with some effort, but I’m not going to do that, as there’s nothing to gain from it. I still think ID’g an ACTUAL VB app that requires that DLL (other than WW!) would be the most informative thing to do, since it would either put WW in a good light (if the app also fails) or not (if the app doesn’t fail), and at least tell us something concrete.
Msconfig is n/a for DLL’s that are registered with Explorer. You actually have to uninstall the app (which unregisters the DLL). What you see in Msconfig are various programs and tasks that are actually executing at launch, which is a different thing. The fact that WinRAR, for example, is listed on a menu in Explorer for your convenience doesn’t mean that it’s loading on startup, because it isn’t. Explorer is merely aware of how to call it when you direct it to do so. These are completely different things.
quote:I agree. I use Windows Explorer by going to Start>All Programs>Accessories>Windows Explorer and I consider the Desktop as being the Shell but you are correct they both execute explorer.exe.
-I'm using the terms Explorer and Windows Explorer and Shell synonymously. I don't think you are.
quote:I agree, [b]nothing[/b] in XP is written in VB or requires VB to run.
Second, the apps I was questioning -- such as OE -- are NOT written in VB at all, let alone an old version. I questioned, then, why they were using the DLL on this particular system but not on others, and further speculated how that might be related to the problem.
You are seeing the VB DLL included in various Windows functions/apps because you have 1 or more apps/utilities/programs installed that is written in VB and has links/addons/pluggins into one or more of Windows’ apps/functions thus when the Windows app such as OE runs it invokes your program’s addon/pluggin/link and pulls in the VB DLL. Your WinRAR could be a candidate for the cause of some of this behavior if it has a link into Explorer and/or OE. My WinZIP has a pluggin/addon for Internet Explorer. Without knowing what you have installed, in addition to Windows, I can only guess which program/s might be the cause.
quote:I disagree. Since Windows doesn't need VB and yet the VB DLL appears indicates one of the apps you have installed that has a link/pluggin/addon into Explorer/Shell and/or OE and etc calls the VB DLL. It's the only way that DLL could be associated with the Windows functions that you are seeing in the Process Explorer window.
none of the apps that ARE hooked into the shell (like WinRAR) use the DLL...
If you really want to find out which of your apps use the DLL, rename the DLL. Whatever pluggin/addon stops working stops because it uses the VB DLL. When invoked the app will produce an error window indicating that it failed cause it couldn’t find msvb…dll.
And when you’re done testing simply rename the DLL back. Certainly easier than imaging the HD. [:)]
quote:I disagree. It doesn't work that way on my XP system.
-Renaming DLL's (or deleting them) simply causes XP to automatically restore them the next time an app calls to use it.
quote:I disagree. While it doesn't stop DLLs from loading directly, it does a nice job of stopping the programs which call suspect DLLs from starting thus stops the DLLs from loading. And it is a much easier means to test changes than doing uninstalls.
Msconfig is n/a for DLL's that are registered with Explorer.
Whew! I’m developing calluses on my finger tips. [:D]
I’m going to bed. [|)]
EdP
Here are some brainstorming thoughts that may lead to a solution.
1) Are you using Admin rights on your workstation?
2) Does it matter what version of .NET is loaded – if at all?
3) (Excerpts from this article) You receive multiple “System files are out of date” error messages when you install a Visual Basic 6.0 application
http://support.microsoft.com/default.aspx?scid=kb;en-us;831491
To obtain the latest Visual Basic 6.0 service pack, visit the following Microsoft Web site:
http://msdn.microsoft.com/vbasic/previous/vb6/downloads/default.aspx (This shows VB 6, SP6d is the latest and that there are some caveats about upgrading from SP5 to SP6)
Note MSVBVM60.dll is also a required file for Visual Basic applications to function. This file is not a system file and is not part of Windows File Protection.
4) Description of the Windows File Protection Feature
http://support.microsoft.com/kb/222193
5) Have you used the System File Checker to check your files? (as described in above article)
Good luck,
PatrickB
Note: the version of msvbvm60.dll it contains is the newer version we’ve been talking about above, and some of the other files are a couple years newer as well. As mentioned before, the problem occurs with either the old or new version, but they might as well have the latest.
Patrick, I see now that the DLL is not part of WFP, which confused me since I did see it replaced before my eyes once I ran WW after having deleted the DLL. It wasn’t WFP though, but another program’s Add/Remove routine stepping in for some reason and doing the restoration itself. So I removed that program and repeated the deletion and running of WW. Now another program’s Add/Remove stepped in to handle it. I removed it as well, and when repeated a third time, and now the file stayed deleted. What I think occurred is that there’s some sort of commonality in the Add/Remove information for VB programs, at least pertaining to important common files like the DLL, and somehow one wanted to intercede on behalf of the other. That’s no longer an issue since those two have been removed, so the file stays deleted.
Thanks
Ed, your WinZIP does add-on to Explorer. See here:
http://www.winzip.com/wzdwinint.htm
I can’t imagine why it would add – what, I’m not sure – to IE, the Internet browser, or what possible benefit that would be, but if you say it’s there I believe you. I haven’t used it in years, but the Explorer capabilities are made very clear in the screenshot and are basically similar to what WinRAR or any other app of this type does (PKZIP etc). Not that you’re forced to install that feature most likely, or if you do install it be penalized in any way for doing so.
But we agree that this seems to center on some existing VB app on this system that is running interference in some way. Since explorer.exe, the shell, is always bound to the DLL according to Process Explorer, then you’re right that this implies some connection between said app and the shell. It’s interesting that most of the apps in the list (Outlook, OE, explorer, and Intellitype) are all MS, though I wouldn’t call any of them “Windows functions” except for the shell and Intellitype.
Now that I can remove the DLL (see previous post), I’ll think about removing and rebooting to see what happens. But Process Explorer has already ID’d the 6 or 7 apps that I tend to run which use the DLL – even though as we’ve established, most are not supposed to – so when one of those bombs, we’ll know why, but not really know anything else.
In other words, it’s not going to point the finger at the app that established the links between the DLL and the MS apps, since that app is never listed in Process Explorer itself. It’s never run. And may not even be installed any longer…