Ex-Employee tells about the Microsoft Windows internal testing process [Bookmarks, +TLDR, +FR]

"Why does Microsoft Windows 10 have so many bugs? Ex-Employee tells you why!"
-- by  Barnacules Nerdgasm
"https://www.youtube.com/watch?v=S9kn8_oztsA"

TL;DR (FR-version) :

1. 1/ Ils ont licensié un département entier de testeurs quand ils ont fusionné leurs multiples systèmes d'exploitation : Desktop , Phone, etc.
2. 2/ Ils ne testent plus du hardware réel; tout est virtualisé (i.e. les problèmes spécifiques au matériel ne sont pas révélés)
3. 3/ Ils se reposent beaucoup sur le _Windows Insider Program_ et la télémétrie pour avoir des remontée de bugs avant de déployer les mises-à-jour "au plus grand nombre" (mais ce mécanisme a des limitations : les utilisateur du _Windows Insider Program_ ne remontent pas toujours les problèmes, les _mini-dumps_ ne sont pas toujours suffisants pour identifier la source d'un problème, les problèmes sont résolus à tâtons, et dans les pire cas, complètement ratés et les correctifs causent davantage de régressions).

TL;DR (EN-version):

1. 1/ They did a massive lay-off and got rid of a whole testing departement when they merged their multiple Operating System teams : Desktop, Phone, etc.
2. 2/ They don't test real hardware anymore; tests are run in virtual machines (ie. hardware-related corner cases are not tested)
3. 3/ They rely a lot on the _Windows Insider Program_ and telemetry before rolling-out updates to "most people" (but this process has limitations : _Windows Insider Program_ users don't always report bugs, _mini-dumps_ aren't always enough for tracking down a bug, some problèmes are solved by groping and, in the worst cases, even missed entirely and attempts to fix a problème cause further regressions).

Picasa photo viewer nostalgia

Picasa 3, the (discontinued) Photo Editor and Viewer was such a great piece of software... There are some replacements (eg. can think of XNView for instance for viewing, and many more for editing...) but none come close to how user friendly Picasa was.

So for those, like me, who want to run this fantastic thing, even if it hasn't been updated in a long time, but still works like a charm, I have an old copy of the installer I am sharing here:

Picasa 3.9

picasa39-setup.exe, 13,0 MB in size

https://1drv.ms/u/s!AtfcQZSwyBPCirMfwnluJUBCkLumBg?e=JOwSFj

I bet you can also find it on FileHippo.com, or some other archiving – file sharing service. But here it is anyway. Enjoy! ;-)

---

If using a deprecated software is not something for you but that you still need to browse high volumes of images scattered in directories, a quick and easy fallback back solution (even if it's not as nice) might be XnView:

choco install -y xnview

Using Chocolatey to install your favorite software

This is a follow-up to one of my previous posts:

Chocolatey is like a package manager, but for Windows; a bit like the famous `apt-get` or `aptitude` for some GNU/Linux distros (...) I have created a curated list of my favorite ones; the ones I would install right away on a new computer, whether it is for work or even for home computing.

Therefore, to run any of the commands listed below, you will first need to install Chocolatey itself, which can be easily done with a simple command, so make sure you first check this post:

Install both Chocolatey and OpenSSH with SSHD in one Copy-Paste in Powershell

---

SUBSEQUENT CALLS

---

After completion, you may invoke commands such as:


# there were problems with former 'linkshellextension' installation
# and there was a bit of an overhead when issuing the commands...
#   choco install -y vcredist2015
#   choco install -y --ignore-checksums linkshellextension
# but it seems to work fine now.


choco install -y linkshellextension

choco install -y 7zip
choco install -y imagemagick
choco install -y git --version 2.21.0

choco install -y openvpn

choco install -y keepass

choco install -y notepadplusplus

choco install -y firefox

choco install -y googlechrome

choco install -y cherrytree --version 0.38.8
choco install -y guidgen-console
choco install -y lightshot
choco install -y synctrayzor

choco install -y winmerge

# java runtime environment
choco install -y jre8

# autoit minimum version: 3.3.8.1
# (autoit 3.3.6.1 not available via chocolatey)
choco install -y autoit --version 3.3.14.5

# scite4autoit3 minimum version: 3.5.4
# (scite4autoit3 3.2.0 not available via chocolatey)
choco install -y scite4autoit3 --version 19.102.1901.001

---

UNUSED

---

# git-lfs is already included in the main Git installer
# (this is true as of early 2019)
choco install -y git-lfs

# syncthing is already part of synctrayzor
choco install -y syncthing

# veracrypt competes with BitLocker on Windows, which works fine

choco install -y veracrypt

# As of May 2019, git-credential-manager-for-windows
# does not seem to be automatically added to the path!
# However this might not be a big deal since it seems
# to have been included into the main Git installer.
choco install -y git-credential-manager-for-windows

# the winbtrfs driver does not work for me
# (but that has nothing to do with Chocolatey)

# I might give it another try at some point though...
choco install -y winbtrfs

---

DEFECTS

---

# As of 2019-05-10, choco installs older v18.2.1 of smartgit,
# which causes problems because we are forced to upgrade as
# soon as it is installed
choco install -y smartgit

---

OTHER COMMANDS: "CHOCO SEARCH"

---

If you want to check if an application is included to the Chocolatey distribution service, or if you want to know its exact name, you may use the "choco search" command.

---

OTHER COMMANDS: "CINST"

---

An even faster way to call for an installation of a piece of software is to use "cinst" instead of "choco install".

Also, according to the help instructions, it should be possible to specify multiple application after the "choco install/cinst" command.

So we can therefore condense the previous list of calls into on single command (although I wrote on multiple lines and escaped using the backtick character, we should be able to copy-paste it just like that):

Optional:

choco feature enable -n allowGlobalConfirmation;

Default base install v2.0.2010.0:

cinst -y linkshellextension; ` cinst -y notepadplusplus; ` cinst -y winmerge; `  cinst -y 7zip; ` cinst -y git; `  ` cinst -y tightvnc; ` cinst -y openvpn; `  ` cinst -y firefox; `  cinst -y googlechrome; `  ` cinst -y jre8; ` cinst -y --version 3.3.14.5 autoit; ` cinst -y --version 19.102.1901.001 scite4autoit3

REMARK #1: Some (generic) lists may include an install instruction multiple times, usually at the beginning or the end of the script, this is on purpose. Lists like this can have multiple purposes and can be partially copy-pasted if we're only interested in a subset of the list. And running the same install request multiple time will only cause it to be ignored (unless the "--force" parameter was used, which is not the case).

REMARK #2: Also some pieces of software require very specific configuration, such as a VNC server, and we're better off running them separately, or at the very beginning and letting the rest of the automated install to carry on...

- tightvnc


REMARK #3: Some software may not be suitable for being installed on the system disk if it deals with data located on an independent disk of a virtual machine, in which case it's advised to use a portable application which you would install manually:

- synctrayzor

REMARK #4: I personally use my favorite (and most important) software in the form of portable programs, which I update myself, in which case it has to be removed from the default list:

- notepadplusplus, keepass, firefox

Other, ready to paste, multi-line commands such as the one above, can be found at this address:

Choco-based unassisted install

Install both Chocolatey and OpenSSH with SSHD in one Copy-Paste in Powershell

---

TL;DR

---

Start a PowerShell console with Administrator privileges and run the following :

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; [System.Net.ServicePointManager]::ServerCertificateValidationCallback = {[bool]1}; set-executionpolicy RemoteSigned -Force -EA 'SilentlyContinue'; iex ((new-object net.webclient).DownloadString('https://gist.githubusercontent.com/deskobj/f135af9b5404c594ee041c1688bc6f0a/raw'))

After the command has exited, we can expect the following to be true:

• CHOCO command available by default via PATH environment variable.
• SSH command available by default via PATH environment variable.
• SSHD service is running.

---

HISTORY OF THE ONE-LINER COMMAND
AND ITS BACK-END SCRIPT

---

The original command (from DarwinJS/ChocoPackages) reads as follows:

[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {[bool]1};set-executionpolicy RemoteSigned -Force -EA 'SilentlyContinue';iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/DarwinJS/ChocoPackages/master/openssh/InstallChoco_and_win32-openssh_with_server.ps1'))

Additionally:

• JUL 26, 2018: Despite the recommendation "Not To", a cached (and modified) version of the script is made available.

• AUG 28, 2018: Enforced TLS 1.2 security protocol use.

• MAY 05, 2019: Added information about how to install Chocolatey on its own, using just a command line.

---

WHAT ABOUT INSTALLING CHOCOLATEY ONLY ?
(WITHOUT THE SSHD SERVICE)

---

To simply install Chocolatey, without SSH support, run the following PowerShell command, as Administrator:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; set-executionpolicy RemoteSigned -Force -EA 'SilentlyContinue'; iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))

If you wish to install SSH later, you can still run the original command even if Chocolatey is already installed (the Choco installation step will just be skipped).

---

PREVENT SYSTEMATIC CONFIRMATIONS
(WHEN YOU KNOW WHAT YOU ARE DOING)

---

Chocolatey always asks if you are sure about installing a piece of software.

One way to address this problem is to always specify the `-y` switch when invoking `choco install`. For instance:

• `choco install -y git`,
• or the even shorter version being `cinst -y git`

But you can also disable this behavior altogether, on a global scale, forever, by running the following command:

choco feature enable -n allowGlobalConfirmation

It's probably a dangerous thing to set up, but it's really nice when you are familiar with the tool and use it repeatedly.

---

MORE SOFTWARE INSTALL SUGGESTIONS

---

Chocolatey is like a package manager, but for Windows; a bit like the famous `apt-get` or `aptitude` for some GNU/Linux distros (`dpkg` for Debian, `yum` for Fedora/RHEL/CentOS or `dnf` for RPM-based distros in general, `yast2` or `zypper` for OpenSuse, `emerge` for Gentoo, `pacman` for Arch). So it allows you to install software easily and effortlessly and the catalog of supported installs is growing.

I have created a curated list of my favorite ones; the ones I would install right away on a new computer, whether it is for work or even for home computing.

Read more:

Chocolatey software installation

Other, ready to paste, multi-line commands such as the one above, can be found on this page:

Choco-based unassisted install

Populate the "Tools" menu entry in Git GUI - Github gist

Please find GitGui-InstallTools.sh as a public Gist on Github.


It is designed to add utilities to the default Git GUI.

You might also want to configure Notepad++ to be your default editor ?

git config --global core.editor "'C:\Program Files\Notepad++\notepad++.exe' -multiInst -nosession -notabbar"

Print system information on top of your desktop background upon startup using BGInfo.exe (Sysinternals)

( Source/Ref.: https://technet.microsoft.com/en-us/sysinternals/bginfo )

Executable with custom template:




https://onedrive.live.com/redir?resid=C213C8B09441DCD7!48680&authkey=!AEUBtQwOZXCSUto&ithint=file%2czip

Drop the the ".exe" and the ".bgi" files in C:\Windows, and schedule task to run at user logon :

    Bginfo.exe BGInfoConf-v160205.1.bgi /nolicprompt /timer:0

Default template:

My template:

Scheduled:

RDP as a different user to Localhost on Windows 7

Concurrent sessions is a feature in server editions of Windows that lets more than one user to log on remotely and use the server at the same time. By default in desktop editions when you connect to a remote computer using Remote Desktop it will force the user who is physically sat at the computer to log off. So how to work around this?

In two steps:

• Crack termsrv.dll, remove the Concurrent Remote Desktop sessions limit, allow multi-user login in XP/Vista at the same time.

• Connect RDC to IP address 127.0.0.2

REFERENCES:

Original patcher:
TCP-Z, Best TCP/IP Patch: Universal Termsrv.dll Patch V1.0b Build 20090425 Release
http://deepxw.blogspot.fr/2009/04/universal-termsrvdll-patch.html

Article commenting on the patcher:
Enable Concurrent Sessions on Windows 7, Windows Vista and Windows XP (Termsrv.dll)
http://digiex.net/guides-reviews/guides-tutorials/windows-guides/1879-enable-concurrent-sessions-windows-7-windows-vista-windows-xp-termsrv-dll.html

Cached version of the patcher executable:
UniversalTermsrvPatch_20090425.zip (Location 4) (Click to download)
https://onedrive.live.com/redir?resid=C213C8B09441DCD7!48685&authkey=!AAdHghvpV7PZ0oM&ithint=file%2czip

Connect Remote Desktop Protocol (RDP) Client To Localhost
(see "Method 1: Connect RDC to IP address 127.0.0.2")
http://www.techbuzz.in/connect-remote-desktop-protocol-rdp-client-to-localhost.php


FURTHER READING:

TCP-Z, Best TCP/IP Patch: Say Bye To Half-open TCP Connections Limit In Vista/2008 SP2
http://deepxw.blogspot.fr/2009/05/say-bye-to-half-open-tcp-connections.html

Redirect terminal service to console (ie. Disconnect RDP and leave computer unlocked)

Usually, when you close your RDP connection the remote computer locks the computer and therefore restricts access and use of your Desktop (COMPUTER LOCKED).

The solution is either :

1/ use VNC instead of RDP

2/ or run "@tscon.exe 1 /dest:console" to transfer your session from RDP to CONSOLE, this will "virtually" kick you out, but it will leave your user session open and your Desktop active on the remote computer.

WARNING: By definition, this solution (2/) is unlikely to work for multiple remote desktop sessions on a single computer at the same time, there can be only one console session and it is already in use.


C:\Users\Administrator2>tscon 2 /dest:console
Could not connect sessionID 2 to sessionname console, Error code 7045
Error [7045]:The requested session access is denied.

One bug in SED.EXE and another in MS-DOS cmd.exe DEL command

That was a fun day, a WTF one (What's The Fun?!). Wasted at least an hour on troubleshooting third party applications... -_-'

Damn'.

Sed.exe temporary file bug

The utility 'sed.exe' (from GnuWin32) helped me in modifying a file during a headless installation process (changing a property in a "web.config" file). Until there, it was fairly cool.


But here comes the less fun part, I noticed that the executable creates a temporary file right in the middle of its working directory. This is a bug listed and commented here:

http://sourceforge.net/p/gnuwin32/bugs/477/.

From what it looks like, the tool may have regressed in Windows 7 again. Unless it's because of the 64 bit system and the WoW emulation...? Anyway.

The temporary file is not that random, first we know where it is located, second, its name is made of 3 known characters 'sed' and 6 random alphanumeric ones. In regular expressions it would be something like

/sed[a-zA-Z0-9]{6}/

So let's rock'n'roll with a workaround. Let's call:

$> DEL /q sed??????

Let's call it in a directory that contains a file sedE1, a file sedE1f8fd, and a file sedE1f8fdBIS. What happens. All three are deleted. WTF?!

Wildcards issue

After further investigations, "sed????" works fine. So what is wrong?

It seems that, as far as wildcards are concerned:

"?????????" <=> "*"

The explanation I found is that DEL works still on the 8.3 character file name model.

So finally the only workaround is to wrap sed.exe into a batch file:

Cloning a Windows VM that is part of a domain using Sysprep.exe

Introduction note

In the writing below, the term "SID" most of the time refers to the "Computer's Domain SID" (the SID of the computer accounts in the Domain). Windows OS also uses local SID(s) but those are meant to be harmless. For more information please read this excellent article from Mark Russinovich (cofunder of Sysinternals and writer of the NewSID tool) : http://blogs.technet.com/b/markrussinovich/archive/2009/11/03/3291024.aspx.

1. Using sysprep to change the SID

Cloning a VM that is part of a domain in order to use it simultaneously along with the original one is hard: on top of changing 1/ the MAC address, 2/ the computer name and 3/ the IP, we always run into mysterious problems when faced with the domain controller.

And there is even worst: the same goes for (some) backups. For instance, I recently backed-up (ie. copied) a VM and upgraded it to Service Pack 3. After the system was upgraded, I switched the VM off and turned the backup on: the domain rejected the old version of the VM. I assume that the controller stored the upgraded system type and refused to grant access to the domain when running an older XP SP2 system. Needless to say, this backup is quite useless :(

So, cloning a VM creates conflicts difficult to solve. Even if it has been taken off the domain prior to duplication! My network administrator pointed out that this is caused by the SID of the machines, but we never really knew what the solution was in order to work around this problem (from a user point of view, not from the network admin point of view). Now, I just found a possible solution in the Xen documents. The tool mentionned below (sysprep) is not specific to Xen, but to Microsoft. (Source: http://xen.org/files/XenCloud/guest.pdf, Chapter "Preparing to clone a Windows VM".)

Computers running Windows operating systems are uniquely identified by a Security ID
(SID). When cloning a Windows VM, it is important to take steps to ensure the uniqueness
of the SID. Cloning an installation without taking the recommended system preparation
steps can lead to duplicate SIDs and other problems. Because the SID identifies the computer
or domain as well as the user, it is critical that it is unique. Refer to the Microsoft
KnowledgeBase article 162001, "Do not disk duplicate installed versions of Windows," for
more information.
sysprep modifies the local computer SID to make it unique to each computer. The sysprep
binaries are on the Windows product CDs in the \support\tools\deploy.cab file.

And, more specifically, the process being:

5. Copy the contents of \support\tools\deploy.cab from the Windows product CD
to a new \sysprep folder in the VM.
6. Run sysprep. This will shut down the VM when it completes.

7. Convert the VM into a template.
8. Clone the newly created template into new VMs as required.
9. When the cloned VM starts, it will get a new SID and name, run a mini-setup to prompt
for configuration values as necessary, and finally restart, before being available for use.

And this important remark:

The original, sysprepped VM (the "source" VM) should not be restarted again after the
sysprep stage, and should be converted to a template immediately afterwards to prevent
this. If the source VM is restarted, sysprep must be run on it again before it can be safely
used to make additional clones.
For more information on using sysprep, refer to the Microsoft TechNet page "Windows System Preparation Tool".

So, in short, two points to be remembered:

1/ running sysprep destroys the SID and shuts the VM down

2/ a new SID is created when the VM is turned back on and added to the domain.

2. Operating systems supported

2.a) XP and Server 2003

sysprep.exe has to be installed separately.

There is a great article that explains how to create a template machine that will also prompt for a new name on next start: http://capitalhead.com/articles/force-sysprep-to-prompt-for-a-computer-name-during-mini-setup-in-windows-xp.aspx

I strongly recommend duplicating the VM before deleting the SID (for backup purpose of course!).

2.b) Windows 7 Professional and Server 2008 R2

I can confirm that sysprep is already present in the C:\Windows\System32\sysprep directory. Note that you have to run Explorer with Administrator privileges in order to see those files (press Win+R and type "sysprep").

3. Template instantiation

Computer makers such as Dell or HP use sysprep.exe to configure the computers: this tool allows you to install and configure programs (or drivers) on a computer, to create local accounts, etc. and then delete the SID and therefore make the computer ready for first use. The template can be copied as many time as you want, but each copy will have to be activated separately, an IP will have to be set for each computer and the Name and Domain configured. And that is it. Every program installed before the SID deletion will remain on the computer. All the user accounts created will remain as well and so does the application data.

An other interesting thing with this process, is that if you had two accounts ( say MYCOMPUTER\Administrator and MYDOMAIN\UserLambda ), then those users will find their desktop just as it used to be before the machine became a template and was re-instantiated again.

But this may have drawbacks and here is an exemple of what NOT to do (yeah I did it, no big deal really, but it creates an overhead of work upon each instantiation): so for instance, 1/ installing LogMeIn Hamachi and creating an account and then 2/ deleting the SID and re-instantiating the VM multiple times is... well, stupid. Hamachi settings are not reset by sysprep.exe because this tool is not part of the system and it does not use the SID either. Therefore every new VM will attempt to use the same Hamachi account and this will cause conflicts. The only solution then is to uninstall and reinstall the Hamachi client on every new computer.

A good practice here would have been to install the Hamachi client before templatisation, but never switch it on (or at least not configure it). The user of each instantiated VM would then already have the program at hand and just would have to run it and create his account himself.

3. Conclusion

I've successfully used the sysprep tool on an server2008 r2 system and it worked great but I did not have such luck with my old XP SP2 system and I will leave it there.

At the end of the day, sysprepping your OS is not very straightforward, but this an irreplaceable process when you need to duplicate a virtual machine that is part of a domain.

Thank you for reading,

Process execution timing in MS DOS cmd.exe batch file

Core

Imagine that you are running a process that takes a long time to perform (eg. build, code generation, maintenance batch, file transfer, etc.) and that you want to see how long it takes. You can use the idea from the sample below. I used a simple "sleep" command in place of a real process, but I believe that you will get the idea.

Usage: In order to use the "timediff" command add the two files

timedff-calc.bat and timediff-sub.bat
to a directory that is in your PATH environment variable (eg. "C:\bin").

https://gist.github.com/deskobj/4757603

Helpers

Consider also adding the following batch script to your toolbox:

Testing

Last but not least, please see the timediff-test.bat file for sample invokations and formats supported:

https://gist.github.com/deskobj/4757647#file-timediff-test-bat

Launch TightVNC using the Computer Name - or - How to Get IP from Computer Name in MS-DOS cmd.exe batch file

First, knowing the name of a computer, we want to get its IP. The script 'GetIpFromName' does that..

Second, we need to call `StartVncViewer MyServerName` to start VncViewer..

See scripts below:

Work around AutoIT stdin limitation

The fastest way to implement a small script and to process a file (or a chunk of data) is to use the standard input rather than file-handles.

1/ It is easier to redirect a file instead of providing parameters to a program.

2/ When you use redirections, the operating system works for you: it opens the file and feeds the program with its content.

C:\> AutoIt3.exe DiffPrettyfier.au3 < MyInput.txt > MyOutput.txt

The content of the script is straight forward:

$myInput = ConsoleRead()

; do something here

; (...)

ConsoleWrite($myOutput)

But there is one problem that makes this a bit harder: AutoIT 'ConsoleRead' doesn't handle input bigger than '65535' characters. So here is a little workaround: use the function 'StdinRead' below instead of 'ConsoleRead':

;-----------------------------------------------------------------

; Name .........: StdinRead

; Description ..: Wrapper for ConsoleRead because it doesn't

; handle big files

; Warning ......: This is a workaround but it has limitations too,

; I used a big file to test this function but it

; might fail on a VERY big file (eg. if the file

; contains 2 147 483 647 characters)

; original big file tested: 18 030 950

; biggest string size allowed: 2 147 483 647

; Parameters ...: n/a

; Return .......: String read on STDIN or empty String "" if

; nothing found on STDIN

;-----------------------------------------------------------------

Func StdinRead()

Const $MAX_BUFFER = 65535

$eofReached = False

$fileContent = ""

While Not $eofReached

$buffer = ConsoleRead($MAX_BUFFER)

If @error Or $buffer = "" Then $eofReached = True

$fileContent &= $buffer

WEnd

Return $fileContent

EndFunc ;==>StdinRead

NOTE: For "ConsoleWrite" to work as expected (redirecting output to stdout), you need to compile the script using the "/console" switch.