MS-DEFCON 2: Getting ready for 2023

Topic

New Reply

ISSUE 20.01.1 • 2023-01-05 By Susan Bradley Once again, we are preparing for another year of patching. And to start out the year auspiciously, I must
[See the full post at: MS-DEFCON 2: Getting ready for 2023]

Susan Bradley Patch Lady/Prudent patcher

2 users thanked author for this post.

abbodi86, lmacri

Reply | Quote

Replies

I’m puzzled at this quote from the posting.

“I recommend that you compare the hidparse.sys file located in c:\windows\System32\drivers\ to the one located in the c:\System32\ folder.”

I thought this one had been sorted out.

Dell Inspiron 16 Plus 7640 Core Ultra 7 155H 32GB Win 11 Pro 23H2 (22631.5189)
Dell Inspiron 15 7580 i7 16GB Win 11 pro 24H2 (26100.4061),
Microsoft 365 Version 2504 (18730.20122)
Location: UK

Reply | Quote

Apologies, I truncated off the c:\windows part as others have pointed out it should read c:\windows\system32.

Susan Bradley Patch Lady/Prudent patcher

1 user thanked author for this post.

John

Reply | Quote

Hi Susan,
I don’t have a ‘c:\System32\ folder’.I’m on W10 21H2; so is it Ok to update?

Reply | Quote

@Frwin, this is an error and should say c:\windows\system32.

The post should read:

“I recommend that you compare the hidparse.sys file located in c:\windows\System32\drivers\ to the one located in the c:\windows\System32\ folder.”

Then it all makes sense.

Dell Inspiron 16 Plus 7640 Core Ultra 7 155H 32GB Win 11 Pro 23H2 (22631.5189)
Dell Inspiron 15 7580 i7 16GB Win 11 pro 24H2 (26100.4061),
Microsoft 365 Version 2504 (18730.20122)
Location: UK

3 users thanked author for this post.

Frwin, Will Fastie, geekdom

Reply | Quote

Hi I have that file in

c:\windows\System32\drivers

and

c:\windows\System32\driverstore\FileRepository…

The second one is not the one concerned ?

1 user thanked author for this post.

Marvel Wars

Reply | Quote

As I pointed out in my post #2512945 in the Several Windows 10 versions affected by blue screen issue topic, the only hidparse.sys files that can cause the BSOD issue are located in C:\Windows\System32\drivers and, if your particular system has one (not all do), in C:\Windows\System32.

All other copies of hidparse.sys located anywhere else on your system are backup copies used by Windows if it detects an “in use” version has become corrupt and needs to be replaced.

2 users thanked author for this post.

Marvel Wars, Frwin

Reply | Quote

I don’t have a c:\system32 folder so am I ok to install december patches on windows 10 21H2 home edition?

Reply | Quote

ConfusedatHome wrote:

I don’t have a c:\system32 folder so am I ok to install december patches on windows 10 21H2 home edition?

The correct folder is C:\Windows\System32 and you have this folder.

Read:
https://www.askwoody.com/forums/topic/ms-defcon-2-getting-ready-for-2023/#post-2514904

On permanent hiatus {with backup and coffee}
offline▸ Win10Pro 2004.19041.572 x64 i3-3220 RAM8GB HDD Firefox83.0b3 WindowsDefender
offline▸ Acer TravelMate P215-52 RAM8GB Win11Pro 22H2.22621.1265 x64 i5-10210U SSD Firefox106.0 MicrosoftDefender
online▸ Win11Pro 22H2.22621.1992 x64 i5-9400 RAM16GB HDD Firefox116.0b3 MicrosoftDefender

Reply | Quote

@sb (Susan Bradley)

Please correct the Alert:
C:\System32 should read C:\Windows\System32

On permanent hiatus {with backup and coffee}
offline▸ Win10Pro 2004.19041.572 x64 i3-3220 RAM8GB HDD Firefox83.0b3 WindowsDefender
offline▸ Acer TravelMate P215-52 RAM8GB Win11Pro 22H2.22621.1265 x64 i5-10210U SSD Firefox106.0 MicrosoftDefender
online▸ Win11Pro 22H2.22621.1992 x64 i5-9400 RAM16GB HDD Firefox116.0b3 MicrosoftDefender

Reply | Quote

Looking at the date stamps of this file, it looks as if both versions (the same file on my Dell XPS) were installed on the same day as the November quality patches, so that update may be responsible.

Interestingly, while the December patches were offered on my  Dell XPS desktop when I changed the group policies delay, they have not been offered on my wife’s laptop (Dell Vostro) although it is 4 days since I changed gpedit. Both are on Windows 10 21H2. I shall wait patiently.

Chris
Win 10 Pro x64 Group A

Reply | Quote

The updates were offered, two days later, on the Vostro after I installed a Dell BOIS update. I suspect the lack of that BIOS update blocked the Windows update for some reason.

Chris
Win 10 Pro x64 Group A

Reply | Quote

John wrote:

I’m puzzled at this quote from the posting.

My fault. I missed it during editing. It’s fixed online, but there’s nothing I can do about the email.

Thanks for keeping me honest!

2 users thanked author for this post.

John, sheldon

Reply | Quote

How about the issues Microsoft created for domain controllers in the November updates regarding lsass and memory leaks.  Were those ever resolved with December’s updates?  Microsoft botched it twice in November.  Still holding off on updating DC’s until we get clarity on that.

Reply | Quote

Yes they were, I reported on that earlier.  I’ve not seen issues in my network and not seen reports of memory leaks in the community after the December update was installed.

Susan Bradley Patch Lady/Prudent patcher

Reply | Quote

Hello, can also confirm that I successfully installed the Dec updates on our Win 2016 DC server last Wednesday and so far no issues.

#SB, acknowledging you appear to be far busier than I. I also don’t remember you mentioning the DC part was fixed, though I assumed no news is good news.

Thank you.

IT Manager Geek

Reply | Quote

Database connections using Microsoft ODBC SQL Server driver might fail

Workaround update.

After installing KB5019980, apps which use ODBC connections utilizing the Microsoft ODBC SQL Server Driver (sqlsrv32.dll) to access databases might fail to connect. You might receive an error within the app or you might receive an error from SQL Server, such as “The EMS System encountered a problem” with “Message: [Microsoft][ODBC SQL Server Driver] Protocol error in TDS Stream” or “Message: [Microsoft][ODBC SQL Server Driver]Unknown token received from SQL Server”. Note for developers: Apps affected by this issue might fail to fetch data, for example when using the SQLFetch function. This issue might occur when calling SQLBindCol function before SQLFetch or calling SQLGetData function after SQLFetch and when a value of 0 (zero) is given for the ‘BufferLength’ argument for fixed datatypes larger than 4 bytes (such as SQL_C_FLOAT)….

Workaround: To mitigate this issue, you can do one of the following:

​If your app is already using or able to use Data Source Name (DSN) to select ODBC connections, install Microsoft ODBC Driver 17 for SQL Server and select it for use with your app using DSN. Note: We recommend the latest version of Microsoft ODBC Driver 17 for SQL Server, as it is more compatible with apps currently using the legacy Microsoft ODBC SQL Server Driver (sqlsrv32.dll) than Microsoft ODBC Driver 18 for SQL Server.
​If your app is unable to use DSN, the app will need to be modified to allow for DSN or to use a newer ODBC driver than Microsoft ODBC SQL Server Driver (sqlsrv32.dll).

Next steps: We are working on a resolution and will provide an update in an upcoming release…

1 user thanked author for this post.

Microfix

Reply | Quote

So now I am confused again, thought this was sorted out.

I have two with the same date, one in

c:\windows\System32\drivers\ identical to the one located in the

c:\windows\System32\driverstore\FileRepository

Do I install the December updates or Defer until the January updates?

Win 10 Home 22H2

Reply | Quote

Bottom line, second one doesn’t count

Reply | Quote

Win7and10 wrote:

I have two with the same date, one in c:\windows\System32\drivers\ identical to the one located in the c:\windows\System32\driverstore\FileRepository

Look 🡹 ~9 posts and you’ll see this question was already answered!

Reply | Quote

Thank you I am just confused.

Bottom line, I am OK then?

Thanks for your support!

Win 10 Home 22H2

Reply | Quote

Win7and10 wrote:

Bottom line I am OK then?

Yes, you are OK with 1 file in c:\windows\System32\drivers\

The other location doesn’t count.

Reply | Quote

Alex5723 wrote:

Next steps: We are working on a resolution and will provide an update in an upcoming release…

Resolution: This issue was resolved in KB5022303. If you have implemented the above workaround, it is recommended to continue using the configuration in the workaround.

Reply | Quote