Every machine I have installed this patch on has this problem now:
Keith Davis
Director of IT, P.R.I.D.E.
MCSA, A+, N+
Keith Davis
Director of IT, P.R.I.D.E.
MCSA, A+, N+
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
943460 Problem! 1
- Thread starter laurin1
- Start date
- Thread starter
- #3
I discovered after I posted it in the Office forum, that this is not an Office problem. It's a Windows XP problem. It affects all my Windows applications.
Keith Davis
Director of IT, P.R.I.D.E.
MCSA, A+, N+
Keith Davis
Director of IT, P.R.I.D.E.
MCSA, A+, N+
Well, that's different than pointing to a thread that describes an Excel only issue.
So none of your XP machines can double click any file and open it with it's associated program?
I'm Certifiable, not cert-ified.
It just means my answers are from experience, not a book.
So none of your XP machines can double click any file and open it with it's associated program?
I'm Certifiable, not cert-ified.
It just means my answers are from experience, not a book.
- Thread starter
- #5
That is correct. I've uninstalled the patch, and they work now. I'm actually in the process of removing the patch from all of my machines temporarily, until I can find a resolution for the problem.
Keith Davis
Director of IT, P.R.I.D.E.
MCSA, A+, N+
Keith Davis
Director of IT, P.R.I.D.E.
MCSA, A+, N+
- Thread starter
- #6
What happens is the application tries to open the several files, instead of one, each compries of a part of the path of to the next space.
Keith Davis
Director of IT, P.R.I.D.E.
MCSA, A+, N+
Keith Davis
Director of IT, P.R.I.D.E.
MCSA, A+, N+
Keith,
I have had that problem before, albeit only with the excel files. Before I discovered the "Ignore other applications" in options, there was a workaround we implemented. On some machines it fixed the problem, but on some, the next time it was updated, the same problem occured, as the fix had been undone. This isn't really a complete solution, but it is a workaround, and may set someone on the right track for the solution.
In windows explorer tools->folder options. Go to the file types tab, and select .xls. In the details for XLS extension, choose advanced (if advanced is not there, click restore, then advanced). In the advanced window, choose under actions, choose "Open". Then click the edit button. in the Applicatation used to perform action: add "%1". Include the quotes. Click ok, ok, apply (if you choose) and ok. This will allow excel files to be opened. On some computers, (Office 2000 and XP), it appears to completely solve the issue. On others (2003), the file will open, along with a dialog box stating that the computer cannot find the file. Once the OK button is pressed on the dialog box, there is no futher issue.
I copied that out of our IT Ticket program. Basically, what it does it tells the computer that there is a string with the entire path not a lot of strings with one word paths (I bet if you were to move a file and rename it so that there were no spaces in the path, you would be able to open the file without a problem).
I would imagine that you would need to follow the same process with each type of file that is having the problem. Like I said, it's not really a total solution, but it did make it so my users could open the files with minimum fuss. I don't know why some computers accepted it fine, and others still threw up the error message, but worked.
Hopefully this will help.
Good Luck!
I have had that problem before, albeit only with the excel files. Before I discovered the "Ignore other applications" in options, there was a workaround we implemented. On some machines it fixed the problem, but on some, the next time it was updated, the same problem occured, as the fix had been undone. This isn't really a complete solution, but it is a workaround, and may set someone on the right track for the solution.
In windows explorer tools->folder options. Go to the file types tab, and select .xls. In the details for XLS extension, choose advanced (if advanced is not there, click restore, then advanced). In the advanced window, choose under actions, choose "Open". Then click the edit button. in the Applicatation used to perform action: add "%1". Include the quotes. Click ok, ok, apply (if you choose) and ok. This will allow excel files to be opened. On some computers, (Office 2000 and XP), it appears to completely solve the issue. On others (2003), the file will open, along with a dialog box stating that the computer cannot find the file. Once the OK button is pressed on the dialog box, there is no futher issue.
I copied that out of our IT Ticket program. Basically, what it does it tells the computer that there is a string with the entire path not a lot of strings with one word paths (I bet if you were to move a file and rename it so that there were no spaces in the path, you would be able to open the file without a problem).
I would imagine that you would need to follow the same process with each type of file that is having the problem. Like I said, it's not really a total solution, but it did make it so my users could open the files with minimum fuss. I don't know why some computers accepted it fine, and others still threw up the error message, but worked.
Hopefully this will help.
Good Luck!
- Thread starter
- #8
I figured it was something like that, but for now, since it's with every type of file and I've got 80 computers, I am just going to uninstall the patch (that does work) and leave it off until I find another solution. It only happens here at work. My home machine does not have this problem with the patch.
Keith Davis
Director of IT, P.R.I.D.E.
MCSA, A+, N+
Keith Davis
Director of IT, P.R.I.D.E.
MCSA, A+, N+
-
1
- #9
This is the famous URI handler patch. The one where Microsoft said "No that's everyone else's problem (Adobe, Firefox, Quicktime, etc)." and then went a couple months later and said "Oh wait, that's our problem too."
What they ended up doing was making URI handling more restrictive in terms of accepting a proper URI. This was done so the problems highlighted by the security issues raised by it could be solved. Regardless of that, what results is that applications that deal with URIs via "ShellExecute" would need to be updated as well.
But in the meantime, you might try the method that is outlined in the KB article for the programs that are broken for not providing a proper URI, at least until they are updated.
- Thread starter
- #10
Your response confuses me. If that is the case, then why are not MS Office applications working as well and why is it only with my office machines, and not my home machine? Both my office machines and my home machine are all on the same domain, but they have some different GP's. Yet, my home machine got the patch and still works fine.
Keith Davis
Director of IT, P.R.I.D.E.
MCSA, A+, N+
Keith Davis
Director of IT, P.R.I.D.E.
MCSA, A+, N+
I was trying to tell you what the reason is for the patch. I will start by saying I don't know the exact changes that were made in 943460. But I will say I'm sure a lot depends on the application at hand, the file at hand, etc. The problem that was addressed by this was widely known (all the PDF spam as of late).
Anyway, for where the issue is coming from, an application, or Windows itself can take a command-line of a document and associate it to a specific application and then open it. This is what Windows does upon a double-click in Explorer (which is the desktop as well).
Now the process then becomes an act of sending a URI to a program, and the program receiving a URI. Basically, though, it's a call to "ShellExecute" in the DLL that is patched in this security update. To look at your other thread, Explorer calls "ShellExecute", which in turn runs the application configured in the shell for "XLS".
Again, I don't know what the code is doing on this new patch (to know that fully I would have to know how to do the exploit in question, and I don't), but it seems the patch might be picking certain known attack vectors (XLS would be one of those, but CSV is not, since it's plain text), and interpreting the passed URI more strictly. Hence, either it is passing three URIs now, or Excel is interpreting the URI as three files.
To use another example illustrating what is going on, I have a COBOL compiler here that was written in the 9X days. The problem with it for XP (or even 98/ME) is that I can't put a source file into a LFN directory and open it via double-click because the compiler interprets the sent URI in much the same way as your excel example. I try to open a source file in "C:\My Documents\Source Files", and it complains about not being able to open "C:\My".
To that end, a lot of how URIs are handled is dictated by how the extensions are configured in the system. For the systems in question, you might try going into Explorer under the File Types section, and look at XLS then go to the Advanced section and look at the definition for "Open" and see if it can be changed. For example, my XLS definition for "Open" is:
Notice the quotes around both the executable path and %1 (the parm used to pass the URI to the program). It may be that the configured call for XLS might not have the " around %1.
Hope that helps, or at least clears up the confusion some.
Anyway, for where the issue is coming from, an application, or Windows itself can take a command-line of a document and associate it to a specific application and then open it. This is what Windows does upon a double-click in Explorer (which is the desktop as well).
Now the process then becomes an act of sending a URI to a program, and the program receiving a URI. Basically, though, it's a call to "ShellExecute" in the DLL that is patched in this security update. To look at your other thread, Explorer calls "ShellExecute", which in turn runs the application configured in the shell for "XLS".
Again, I don't know what the code is doing on this new patch (to know that fully I would have to know how to do the exploit in question, and I don't), but it seems the patch might be picking certain known attack vectors (XLS would be one of those, but CSV is not, since it's plain text), and interpreting the passed URI more strictly. Hence, either it is passing three URIs now, or Excel is interpreting the URI as three files.
To use another example illustrating what is going on, I have a COBOL compiler here that was written in the 9X days. The problem with it for XP (or even 98/ME) is that I can't put a source file into a LFN directory and open it via double-click because the compiler interprets the sent URI in much the same way as your excel example. I try to open a source file in "C:\My Documents\Source Files", and it complains about not being able to open "C:\My".
To that end, a lot of how URIs are handled is dictated by how the extensions are configured in the system. For the systems in question, you might try going into Explorer under the File Types section, and look at XLS then go to the Advanced section and look at the definition for "Open" and see if it can be changed. For example, my XLS definition for "Open" is:
Code:
"C:\Program Files\OpenOffice.org 2.3\program\soffice.exe" -calc -o "%1"Notice the quotes around both the executable path and %1 (the parm used to pass the URI to the program). It may be that the configured call for XLS might not have the " around %1.
Hope that helps, or at least clears up the confusion some.
What a URI is, think basically a path to a local file, remote file, or Internet resource.
- Thread starter
- #13
I understand what a URI is, but my problem is that MS is trying to "fix" something, without providing a solution to what they "fixed". 
Keith Davis
Director of IT, P.R.I.D.E.
MCSA, A+, N+
Keith Davis
Director of IT, P.R.I.D.E.
MCSA, A+, N+
- Status
Similar threads
- Locked
- Question