Quantcast
Channel: Microsoft forum - dslreports.com
Viewing all articles
Browse latest Browse all 8524

[WIN8] Why is the Windows Journal.lnk so special???

$
0
0
Everyone, The title really says it all. What is so special about this link? [attachment=1] By the way, get ready for a long post. This is something that has bugged me for a while now! :) On a default install of Windows 8.1, that link is located here C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Accessories\Tablet PC\Windows Journal.lnk My understanding of shortcuts was that they were created so that the end user could move them around to any location on the system that was convenient to them. This way, the actual location of what the shortcut pointed to (EXE, Drive, folder, music files, pictures, etc) could be left alone. Not to mention, a user may not have the needed rights to move EXE's or specific folders, and it also helps keep things like Program EXE's from being modified by normal users (non admins). Shortcuts could also be renamed to fit your needs better, or change the icon if one does not like the default one. However, in Microsoft's eyes, there apparently is something special with the "Windows Journal" shortcut. Let me explain why. I'm one who does a lot of customizations to the Start Screen directory structure to fit my needs and work habits. The two directories I modify are C:\ProgramData\Microsoft\Windows\Start Menu\Programs and C:\Users\xxx\AppData\Roaming\Microsoft\Windows\Start Menu\Programs (btw, xxx = user profiles) One of the many things I do is to move the location of the Windows Journal shortcut from its default location to C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Windows Accessories\Windows Journal.lnk. I have installed every patch that has come out for Windows 8.1, and have had no problems with the changes that I have made, EXCEPT for the following Patches: Microsoft Security Bulletin MS13-054 -Vulnerability in GDI+ Could Allow Remote Code Execution (2848295) https://technet.microsoft.com/library/security/MS13-054 Microsoft Security Bulletin MS14-038 - Vulnerability in Windows Journal Could Allow Remote Code Execution (2975689) https://technet.microsoft.com/library/security/MS14-038 With my changes in place, if I try to install either of these two, the update will fail with either error code: 0x80070003 0x80070002 However, if I go and put the Windows Journal shortcut back in its default location, the patches will install without any problems. I do want to point out that never in any of the logs does it come right out and say that it cannot find the Windows Journal Shortcut. I figured this out by looking at what components were effected by the two patches, and made a guess that the system was looking for Windows Journal. I also want to add that at no time do I ever move, rename, modify, or change the location of the actual Windows Journal EXE, which is located at C:\Program Files\Windows Journal\Journal.exe When I was first having issues with MS13-064), I started a thread on this site. That thread is here http://www.dslreports.com/forum/remark,28474423?hilite=ms13 I never did fully test putting the Windows Journal shortcut back in its default location, but the research that was done by others members that posted to that thread lead me to believe that if I undid all of my changes, the patch would install. So, I did a reinstall of the OS, made zero changes, and installed the patches. Since the Windows Journal Shortcut was in its default location, the patch installed. Then, when MS14-038 came out, I had the same issues. I started a new thread, which is below http://www.dslreports.com/forum/r29378000-WIN8-Another-MS-Patch-that-won-t-install-MS14-038-SOLVED In that one, I noticed right away that MS14-038 superseded MS13-064, so it was probably the same reason for failure. It was then that I did the research to find out that both patches effected Windows Journal, and it was uid://1354951 that helped me remember where that default install location was at. Once I put the Windows Journal shortcut back to its default location, I was able to install MS14-038. And now today I can add this one Microsoft 8.1 August 2014 Update (aka Windows 8.1 Update 2) http://support.microsoft.com/kb/2975719 It, like the other two, failed with the same error code(0x80070003). I then created the default directories, and put the shortcut back to where it was on a default install. Re-ran the update, and bingo! No more issues. So, the bottom line here is this. Why does Microsoft find it necessary to check for the location of, and existence of, a Shortcut instead of the actual EXE that the shortcut is pointing at, to determine if a given patch should be applied? Not to mention, whatever checking is done by Windows Update to offer me the patch WORKS with my modifications in place (meaning, the Windows Journal shortcut is not in its default location). Yet, Windows Update will tell me, if the patch has not already been applied, that I need to install MS13-054 or MS14-038. The issue comes up during the actual install of the patch itself (either from Windows Update, or if I manually download the patch files). There is some check or verification that the actual patch does that apparently requires or is looking for, the Windows Journal shortcut to be in its default location. If its not there, the patch will fail to install. Thoughts? Any one have any reason why this is? Why do the patches need to verify a shortcut and not look for the EXE itself? If possible, I would love to be able to contact Microsoft and ask them about this, and see what they come back with. Does anyone have a suggestion as to how I would go about doing that? This has been bugging me for a while now. Not to mention, since I've now came across 3 patches that have this same issue, I figured it was time to try to find some answers. Thanks for reading. --Brian -- ============================ --Brian Plencner E-Mail: CoasterBrian72Cancer@gmail.com Note: Kill Cancer to Reply via e-mail

Viewing all articles
Browse latest Browse all 8524

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>