Replies

app is Album Art Downloader.  Problem appears to be just W7, and was present with both March Updates [Qual and Security] and again in April.  It is not related to .Net update from March, that worked fine and is still installed.  Must be in some foundational library in MS’s stuff.  The app uses web access library to query many different album cover sites and present results to user, has been around for many years and works well, but not seeing the cover results makes it pretty usless! BTW, you can still click the “grey placeholder” and download the cover, and the resulting file is just fine and looks fine [in irfanview], it’s just that you can’t see the displayed image.  Sounds VERY SIMILAR to the reported problems with PRINTING graphics, but here we’re talking the display.  [And last month’s “fix printing” update from mid-month did not fix it].

–Paul

 

Thanks for the tip.  As of this time, the compatability tab doesn’t have a “Change High DPI” button, just the older checkbox to “disable display scaling…”.  But I’ll keep this tip tucked away for future ref.

I have not heard anywhere of others with this or similar issue, perhaps it was just my bad experience, but removing KB5000841 did “fix” it, I will hold off trying that update again for 4 weeks or so and see what develops…

 

I posted here with info and conclusion:

https://www.askwoody.com/forums/topic/ms-defcon-1-blue-screens-of-death-triggered-by-patches/#post-2349725

I repeat it here for your convenience:

re:   W7 x64   KB5000841   March 2021 Quality Rollup

I have confirmed that this rollup _DEFINATELY_  has a bug that causes one of my dotNet 4  based applications to no longer display jpg images [and maybe other image types too, like png’s].  The app is Album Art Downloader, a long standing well debugged app, I’ve used it for years.

After this update the app would no longer display any pictures, just grey-box place-holders; when asked to save those images it saved perfectly fine files that could be viewed ok.  So it’s a displaying-to-the-screen issue, not a network or file issue.

I thought the problem was the March dotNet 4.8 update, but it was not, since removing that did not fix things.

Instead removing KB5000841 solved the problem, the app now works normally again [and the March dotNet 4.8 updates _ARE_ still installed].

So, the March W7x64 Monthly is not ready for prime-time either…

-=Paul=-

 

 

re:   W7 x64   KB5000841   March 2021 Quality Rollup

I have confirmed that this rollup _DEFINATELY_  has a bug that causes one of my dotNet 4  based applications to no longer display jpg images [and maybe other image types too, like png’s].  The app is Album Art Downloader, a long standing well debugged app, I’ve used it for years.

After this update the app would no longer display any pictures, just grey-box place-holders; when asked to save those images it saved perfectly fine files that could be viewed ok.  So it’s a displaying-to-the-screen issue, not a network or file issue.

I thought the problem was the March dotNet 4.8 update, but it was not, since removing that did not fix things.

Instead removing KB5000841 solved the problem, the app now works normally again [and the March dotNet 4.8 updates _ARE_ still installed].

So, the March W7x64 Monthly is not ready for prime-time either…

-=Paul=-

 

Today I find that .net applications can not display jpg files.

 

W7x64  ESU, I did the two .net 4.8 V2 updates followed by 2021-March Rollup.

 

Anyone else in same boat?

FWIW, been checking this for last 3 days, my W7HomePremx64  _DOES_ still offer the Oct Rollup, but it is unchecked.  It’s now Monday 13:50 edt and it’s still offering it.  So…

I have had the serving-stack-updates installed since July’16 and Sept’16 when they were originally released.

FWIW, ASRock has offered BIOS updates this year with updated microcode. My 2014 H97 chipset MoBo had a bios update in March’18 for Haswell CPU’s, updating m/c from 0x19 to 0x24.  As of Aug’18 Intel’s latest Haswell Desktop m/c is 0x25.

So, Dell isn’t the only one serving their user base…

 

I too am in the same boat, ASRock w/ Haswell and Win 7 x64 from a few years back.  FWIW, here’s some info I have gathered over the past few days.

1) Intel releases microcode FOR LINUX on a fairly regular basis. You can use it too, see #2.  The path is “https://downloadcenter.intel.com/download/27431”.  This database update came out on 8JAN18, and IS THE ONE CAUTIONED AGAINST NOW.  On that page you can see the previous releases, the last being 11NOV17 .

2) To make use of this you need to go here:  “https://labs.vmware.com/flings/vmware-cpu-microcode-update-driver#instructions”.  This will install a Windows driver that updates your microcode on every startup.  READ THE INSTRUCTIONS, it isn’t really that hard.  ALSO READ THE COMMENTS, there have been MANY over the last few days.  This driver works well (and has for years) HOWEVER it appears that it runs TOO LATE in the start-up sequence for the new Microsoft Windows code update to notice – Win sees the old (bios) uCode version number.  MS NEEDS TO *FIX* THIS, IMHO, but they may not realize it  yet.  It should not be too hard to do a “later” double check.  Anyway, the VMWare people may beat MS to the punch by updating their driver to run much earlier; it is a KERNEL_LEVEL driver now, there is such a thing as a BOOT_LEVEL driver but those have far fewer resources to build upon; and since it works great as it is they really don’t have any responsibility here [but they ARE listening and giving feedback – GREAT GUYS ALL AROUND – THANK YOU VMWare Gurus!]

3)  Microsoft COULD and SHOULD [and MUST!] just update the uCode themselves and then they would be 100% sure of the config – they used to do just that, but haven’t bothered in years;  the win-supplied file mcupdate_GenuineIntel.dll dates to 2010!  They could just update that, and maybe someday they will…

4)  So, what’s in this new microcode? Two things apparently: a few existing instructions have had minor modifications made to them that slightly changes their branch prediction semantics, and 2) a few BRAND NEW instructions have been created that an OS can use to “get around” the Meltdown/Spectre problems (if properly utilized!).  That’s why you need both uCode and Patches for a complete fix.

————-

So for Haswell fans, my Mobo bios has microcode version 19, the last available from ASRock (August 2015).  The 11NOV17 (and many prior) Intel db mentioned above takes that to 22 – It has worked just fine for a long time now.  The 08JAN18 update took it to 23; I tested it and it did install and booted fine, showing up as 23 (as the releasenote said it would, and HWINFO.EXE confirmed).  I then went right back to 22, and plan to stay there for (ever) now.  I imagine version 24 is not too far off…

But ultimately, I don’t think I _EVER_ want this “fix”.  Toward that end I have taken an Image Snapshot of my system and named it “BEFORE_DEGRADATION.TLB” and stored it away carefully.  I suspect I will be restoring from it many times in the future…

-=Paul=-

 

5 users thanked author for this post.

SueW, Karlston, amraybt, Steve S., HiFlyer

FWIW I installed the said “fix” and then Windows Update came back and told me I had over 20 important updates and a few recomended ones that needed to be installed.  Apparently some of the files that are installed are rather old versions (dating back to aug of 2016), just a few are actually newer than 20aug17 (according to autoruns).  It does change many dll’s. (autoruns’ “compare” facility is great!).

I did a a system restore to the point that this “fix” made for me and and it’s back to the way it was.   It might be wise to hold off on this “fix” for a bit until this all gets sorted out…

 

5 users thanked author for this post.

HiFlyer, MrBrian, Elly, Microfix, AJNorth