yeah, you are right. After further investigation, I think KB2544514 replaces KB2534614, kb2551782, kb2478063 & 2565600.
Guys, do you know how to solve the problem of these weird arrows? View attachment 12309 For my last build of Windows 7 SP1 integrated with hotfixes from SoLoR's repo 2 months ago, my start menu was fine. This problem occurs for my latest build with latest hotfixes from SoLoR's repo up to now. Perhaps, some of the recent added hotfixes have broken the arrows, not just in Start Menu, but also in Internet Explorer 9 as well. Thank you to those who can offer useful advice to me.
No problem here with all the latest updates, arrow is a proper arrow. Before you ask I did set in the start menu options to display the control panel as a menu, which enables the arrow, and not as a link which opens up the separate control panel. From what it looks like, on your computer the resource pointer for the arrow has been changed somehow. The icon that you now have is a mouse icon! I don't recall seeing that particular mouse icon anywhere, but its pretty obvious what it is
The link has spaces in it. Spaces aren't actually allowed in web addresses, the space gets replaced by %20. In most cases this should be avoided since the handling of it is often incorrect, particularly in service request links in email (like when you request a hotfix from Microsoft), weblinks etc. If the link doesn't work by clicking on it, right hand click on it and use 'Open in New Tab' instead. This often resolves the issue. In other situations where the whole web address is showing but the hyperlink is only partial, you need to highlight the whole line, copy, and paste into a new tab (in recent of Firefox you can actually highlight text based links like that and right click --> open in new tab instead of manually doing it).
@burfadel Thanks for your advice, but I am still unsure on how to solve this problem. We all know that there are probably 1% of the installation of these not-extensively tested LDR hotfixes, that will cause problems. Guess that I am the unlucky one. Anyway, Windows runs fine in my system. It just looks hideous with those unsightly "arrows". Quoted from the link given by oinkers: Maybe we can exploit this feature to include all post-SP1 hotfixes inside the Updates folder. The file names should be named as follows: 1. Setup customization .msp file: named as 1_customization.msp 2. msp files from SP1 installer (such as officesuitemuisp1-en-us.msp, officesuitewwsp1-x-none.msp and etc.): named as 2_officesuitemuisp1-en-us.msp, and so on. 3. post-SP1 msp files (such as excel-x-none.msp and mso-x-none.msp): named as 3_excel-x-none.msp, and so on. If we name the msp files this way, msp files from SP1 installer would be installed first before post-SP1 msp files. Thus, we could straight away install full-updated post-SP1 M$ Office 2010 at one go. So, guys, do you think this will work? Thanks for the comments.
I'm not sure how to fix it either, but I'm guessing something possible third party may have caused it... Try going to C:\Users\[your user name]\AppData\Local and deleting the iconcache.db file and then reboot.
Deleting iconcache.db wont work if explorer is running, try this in a bat/cmd file Code: start /WAIT taskkill /F /IM explorer.exe del /F /Q "%LocalAppData%\iconchacke.db" explorer
Yeah, better be real careful of that iconchacke! Code: start /WAIT taskkill /F /IM explorer.exe del /F /Q "%LocalAppData%\iconcache.db" explorer Apparently still a good idea to restart afterwards. I believe if you don't kill explorer, the current cache file will stay in memory, but will be replaced anyway on next boot... In any case, whichever way you do it, apart from deleting the elusive icon chacke file , it should hopefully resolve your issue.
You're right- the LDR branch in one of the updates could be causing the quirk you see. But I really don't think that's the case since there'd be at least one other person here who'd also be seeing it. Could it be a corrupt user profile? Does it happen if you log in as another user? ( hxxp://windows.microsoft.com/en-US/windows7/fix-a-corrupted-user-profile ) System file corruption? Try running sfc.exe. Corrupt user theme? Try a different theme. Newer video driver available? If you do think it's a problem related to the LDR branch, back out updates for components that could affect areas where you're having problems (like shell32.dll) and get them back to GDR. If you take that route, might try focusing on these first: kernel32: KB2549760 OS kernel: KB2566205 OS kernel: KB2590443 ntdll: KB2582203 userenv.dll: KB2600484 kernel resources: KB2604521 shell32: KB2610379 shell32: KB2615128 kernel32: KB2615701 gdi32: KB2616332 usp: KB2618517 That is exactly the way the post-SP1 Office .msp files are supposed to be used- to be included in the \Updates folders. As you mentioned, you should rename the setup customization file (if used) with a "1" at the beginning of the name but I don't think you need rename the others- just drop all (SP1 and post-SP1) .msp's in there and they'll be installed all at once during the initial install in the proper order. Renaming with the numbers, as you mention, might be a good idea though, just to make sure the SP1's get installed before post-SP1's. The link that says MS recommends not using .msp's refers only to applying Office updates after the initial install has been completed. MS recommends using the full update .exe then (instead of the extracted .msp). Using .msp's (SP1 & post-SP1) during initial Office install via the Updates folder works fine though and is the recommended way to use them. Random thought: it would be great if SoLoR could add to the repository a folder for the original Office hotfix install .exe's (in addition to the current extracted .msp's) for those who are applying updates to Office that's already been installed. By using the .exe's, it would be easier to remove older updates as they become superseded. But I guess things are working ok as they are now and the unextracted updates can be obtained directly from MS..
Its unlikely this icon issue is caused by a LDR update over a GDR. First of all, like mentioned, it would be a common thing found on here since most people, either purposefully or just the way it works out, use the LDR branch updates. Secondly, an icon issue like this is so very extremely unlikely to have a system specific cause, that is, something that affects one computer or a small percentage of computers. If for example you are running 5 screens, all with different resolutions, 4 through displayport and one through a DVI-HDMI connector, and you have issues moving an app between the displayport and HDMI screens, and this issue only started after you had run a interface related update. Its something that would be very system specific. BTW, I couldn't think of a better hypothetical example on the spot that would be system specific enough! Anyways, this icon issue is definitely a result of resource corruption, whether its the icon cache, WMI repository (why that would affect it, I don't know, just saying!), WinSxS corruption, registry pointers/keys/values, effects of a virus, trojan, or other malware, etc. This is not to say that uninstalling and installing the updates won't work, it may 'reset' the resource corruption issue, but it does not mean that the update is the cause of the issue
So it would seem that one or more of the hotfixes in solor's updates causes the execution of mscorsvw.exe to execute upon first boot. Can anybody think of a way to prevent its execution? I'll manually run it after .net 4.5 installation.
If so, wouldn't that be one of the NET 3.5 updates? As those are part of the msu/win updates, not the net4 ones.
Check these since they seem to be .NET related: Windows6.1-KB2569389-x64.msu Windows6.1-KB2443643-x64.msu Windows6.1-KB2497453-x64.msu Windows6.1-KB975410-v2-x64.msu Windows6.1-KB2518869-x64.msu Windows6.1-KB2539635-x64.msu Windows6.1-KB2575509-x64.msu Windows6.1-KB2598773-x64.msu Windows6.1-KB2600100-x64.msu Windows6.1-KB2605597-x64.msu Try using "ngen queue pause" to temporarily stop the processing, then "ngen queue continue" when you want it to finish processing. I don't know if you can completely prevent it from executing, unless you disable the Microsoft .NET Framework NGEN services, then re-enable them later.