Microsoft May Already Have a Reliability Strategy

Page 3 of 5 FirstFirst 12345 LastLast

  1. Posts : 7,128
    Windows 10 Pro Insider
       #20

    BunnyJ said:
    The ever changing life cycle was the plan with 10,, at least that was/is my understanding. The big difference is that with previous versions of Windows the updates were few and very far between but now they're almost non stop, insider builds. FWIW, I like this approach more than the previous one. It was painful to wait a year or more to get major updates.

    And.. so far I'm not having any issues.,.. luck??
    This is OK for Insider builds and one reason why I joined. It's not in MS's best of interest to release to the general public any updates or upgrades before they are ready. Any updates or upgrades should not introduce more problems than they fix.
      My Computers


  2. Posts : 22,740
    Windows 10 Home x64
       #21

    Winuser said:
    This is OK for Insider builds and one reason why I joined. It's not in MS's best of interest to release to the general public any updates or upgrades before they are ready. Any updates or upgrades should not introduce more problems than they fix.
    How long would you like them to wait before releasing new things and/or updates??
      My Computer


  3. Posts : 7,128
    Windows 10 Pro Insider
       #22

    BunnyJ said:
    How long would you like them to wait before releasing new things and/or updates??
    For the General public? Not until most if not all the bugs are worked out. As Insiders we volunteered to test out new features in Windows 10 and know ahead of time that we may encounter problems. The general public just wants a OS that works. Don't forget that MS did their best to either convince or sneakily force people to upgrade. IMHO a working OS for the general public is not asking for to much.
      My Computers


  4. Posts : 22,740
    Windows 10 Home x64
       #23

    Winuser said:
    For the General public? Not until most if not all the bugs are worked out. As Insiders we volunteered to test out new features in Windows 10 and know ahead of time that we may encounter problems. The general public just wants a OS that works. Don't forget that MS did their best to either convince or sneakily force people to upgrade. IMHO a working OS for the general public is not asking for to much.
    The issue still is that there's really no way to make sure all of the bugs are out of a new build. While it would be nice to have a bug free OS.. I don't see that occurring.
      My Computer


  5. Posts : 15,027
    Windows 10 IoT
       #24

    I agree with all of the above but! There have been some big gotchas slipping threw the cracks. Like I said earlier, how is it they don't show up in the insider builds but crop up at the last moment when a consumer build is released? They were patching the last insider build days before it became the consumer build. And more patches right after it was released? Isn't the whole point of insider builds so the kinks get worked out before it hits consumer PC's? What part of the puzzle am I missing?
    Put all the new features you want in the insider builds, but at some point you have to draw a line in the sand and stop adding stuff. Then fix what ever is broken. And don't wait until the day before releasing it to the consumer side to do it. IMHO the AU was not ready for prim time.
      My Computer


  6. Posts : 22,740
    Windows 10 Home x64
       #25

    alphanumeric said:
    I agree with all of the above but! There have been some big gotchas slipping threw the cracks. Like I said earlier, how is it they don't show up in the insider builds but crop up at the last moment when a consumer build is released? They were patching the last insider build days before it became the consumer build. And more patches right after it was released? Isn't the whole point of insider builds so the kinks get worked out before it hits consumer PC's? What part of the puzzle am I missing?
    Put all the new features you want in the insider builds, but at some point you have to draw a line in the sand and stop adding stuff. Then fix what ever is broken. And don't wait until the day before releasing it to the consumer side to do it. IMHO the AU was not ready for prim time.
    The AU did receive lots of testing when it was in the insider program and I don't know how much more testing is needed. If you're missing any part it's that it's impossible to test the OS on every possible PC part combination and set up that users have. If fewer people with a wide variety of PC's test then the test results via the insider program are not going to be as good. The solution.. well people need to either get more involved.

    If you recall the last few months before the AU came out no new features were added and the only thing that was being done was bug repairs.
      My Computer


  7. Posts : 7,128
    Windows 10 Pro Insider
       #26

    BunnyJ said:
    If you recall the last few months before the AU came out no new features were added and the only thing that was being done was bug repairs.
    No new features were added but MS had to make some last minute changes somewhere before the AU was released. MS needs to learn that even though most Insiders expect to encounter problems the general public doesn't. They just want a OS that works.
      My Computers


  8. Posts : 27,166
    Win11 Pro, Win10 Pro N, Win10 Home, Windows 8.1 Pro, Ubuntu
       #27

    Winuser said:
    No new features were added but MS had to make some last minute changes somewhere before the AU was released. MS needs to learn that even though most Insiders expect to encounter problems the general public doesn't. They just want a OS that works.
    The biggest problem users are having with the AU is, the OEM's have not updated their certificates for their drivers, before Microsoft tightened the screws(which they said they were going to do loooong ago). So it was the OEM's that dropped the ball and not Microsoft, who is trying to make our systems safer, and protect against kernel mode Rootkit Malware.
    information   Information

    Kernel mode

    Kernel-mode rootkits run with the highest operating system privileges (Ring 0) by adding code or replacing portions of the core operating system, including both the kernel and associated device drivers. Most operating systems support kernel-mode device drivers, which execute with the same privileges as the operating system itself. As such, many kernel-mode rootkits are developed as device drivers or loadable modules, such as loadable kernel modules in Linux or device drivers in Microsoft Windows. This class of rootkit has unrestricted security access, but is more difficult to write.[27] The complexity makes bugs common, and any bugs in code operating at the kernel level may seriously impact system stability, leading to discovery of the rootkit.[27] One of the first widely known kernel rootkits was developed for Windows NT 4.0 and released in Phrack magazine in 1999 by Greg Hoglund.[28][29][30] Kernel rootkits can be especially difficult to detect and remove because they operate at the same security level as the operating system itself, and are thus able to intercept or subvert the most trusted operating system operations. Any software, such as antivirus software, running on the compromised system is equally vulnerable.[31] In this situation, no part of the system can be trusted.
    A rootkit can modify data structures in the Windows kernel using a method known as direct kernel object manipulation (DKOM).[32] This method can be used to hide processes. A kernel mode rootkit can also hook the System Service Descriptor Table (SSDT), or modify the gates between user mode and kernel mode, in order to cloak itself.[3] Similarly for the Linux operating system, a rootkit can modify the system call table to subvert kernel functionality.[33] It's common that a rootkit creates a hidden, encrypted filesystem in which it can hide other malware or original copies of files it has infected.[34] Operating systems are evolving to counter the threat of kernel-mode rootkits. For example, 64-bit editions of Microsoft Windows now implement mandatory signing of all kernel-level drivers in order to make it more difficult for untrusted code to execute with the highest privileges in a system.[35]
    Rootkit - Wikipedia, the free encyclopedia
      My Computers


  9. Posts : 27,166
    Win11 Pro, Win10 Pro N, Win10 Home, Windows 8.1 Pro, Ubuntu
       #28

    Additionally:

    NOTE: These driver signing changes correspond to the initial Windows 10 release. For driver signing changes in Windows 10, version 1607, see this post.
    Beginning with the release of Windows 10, all new Windows 10 kernel mode drivers must be submitted to and digitally signed by the Windows Hardware Developer Center Dashboard portal. Windows 10 will not load new kernel mode drivers which are not signed by the portal.
    Additionally, starting 90 days after the release of Windows 10, the portal will only accept driver submissions, including both kernel and user mode driver submissions, that have a valid Extended Validation (“EV”) Code Signing Certificate.
    We’re making these changes to help make Windows more secure. These changes limit the risk of a driver publisher’s signing keys being lost or stolen and also ensures that driver publishers are strongly authenticated.
    If you are a driver developer, here is what you need to do:


    1. Ensure that you submit new drivers to Microsoft via the Windows Hardware Developer Center Dashboard portal.
    2. Get started with the process of getting an EV Code Signing Certificate.

    FAQs
    What about existing drivers? Do I need to re-sign these drivers to get them to work with Windows 10?
    No, existing drivers do not need to be re-signed. To ensure backwards compatibility, drivers which are properly
    Driver Signing changes in Windows 10 Windows Hardware Certification blog
      My Computers


  10. Posts : 27,166
    Win11 Pro, Win10 Pro N, Win10 Home, Windows 8.1 Pro, Ubuntu
       #29

    FAQs

    What are the exact exceptions? Are cross-signed drivers still valid?
    Enforcement only happens on fresh installations, with Secure Boot on, and only applies to new kernel mode drivers:

    • PCs upgrading from a release of Windows prior to Windows 10 Version 1607 will still permit installation of cross-signed drivers.
    • PCs with Secure Boot OFF will still permit installation of cross-signed drivers.
    • Drivers signed with an end-entity certificate issued prior to July 29th, 2015 that chains to a supported cross-signed CA will continue to be allowed.
    • To prevent systems from failing to boot properly, boot drivers will not be blocked, but they will be removed by the Program Compatibility Assistant. Future versions of Windows will block boot drivers.

    To summarize, on non-upgraded fresh installations of Windows 10, version 1607 with Secure Boot ON, drivers must be signed by Microsoft or with an end-entity certificate issued prior to July 29th, 2015 that chains to a supported cross-signed CA.
    What about existing drivers? Do I need to re-sign these drivers to get them to work with Windows 10, version 1607?
    No. Existing drivers do not need to be re-signed. To ensure backwards compatibility, drivers which are properly signed by a valid cross-signing certificate issued prior to July 29th, 2015 will continue to pass signing checks on Windows 10, version 1607.
    What about older versions of Windows?
    The changes described in this post apply only to Windows 10, version 1607. Please note that the Windows Hardware Developer Center Dashboard portal will require all new submissions be signed with an EV Code Signing Certificate no matter what OS you plan to support with your driver package.
    How do I sign drivers during development and testing?
    Please see the Signing Drivers during Development and Test topic on MSDN for information on how to test sign. In addition, if Secure Boot is set to OFF, then drivers signed with existing cross-signed certificates will continue to be valid.
    How do I sign a driver so that it is compatible with Windows Vista, Windows 7, Windows 8, Windows 8.1, and Windows 10?
    All you need to do is run the HLK tests for Windows 10 and run the HCK tests for Windows 8.1 and earlier versions as you have in the past. Then, using the Windows 10 HLK, merge the two test logs and submit your driver along with the merged HLK/HCK test results to the Windows Hardware Developer Center Dashboard portal. The portal will sign the driver correctly such that it will work on all platforms that you indicate.
    What about Extended Validation Certificate Dev Portal package signing?
    The portal currently requires all driver submitters to have a valid EV Code Signing Certificate registered to their account. Windows itself does not have any special requirements for drivers to be signed by EV certificates.
    Driver Signing changes in Windows 10, version 1607 Windows Hardware Certification blog
      My Computers


 

  Related Discussions
Our Sites
Site Links
About Us
Windows 10 Forums is an independent web site and has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. "Windows 10" and related materials are trademarks of Microsoft Corp.

© Designer Media Ltd
All times are GMT -5. The time now is 08:25.
Find Us




Windows 10 Forums