Written Rubberducking: A Practical Example

In my article yesterday, I wrote about the benefits of "Written Rubberducking":

In addition to the benefits of spoken rubberducking, you get these additional benefits:

• Focuses your thinking
• Builds reference material (for you and others) in case the same error reappears
• Helps others get up to speed quickly on what you’ve tried and where you’re having trouble if you need help
• Helps you get up to speed quickly if you get interrupted while debugging and have to come back to it later
• Justifies time spent on an issue (for your boss or client)

Today I'm going to show you an example of this concept in action.

Tell it to the Kiwi

At Grandjean & Braverman, we use FogBugz as our bug database.  

The same concepts apply, though, no matter what you use for issue tracking: GitHub, Jira, Asana, a wiki, or even a Word document.  

At a minimum, you need the ability to:

• Write text and save screenshots

Ideally, your solution supports additional features, such as:

• Easy to share data with colleagues
• Entries are threaded with timestamps and name of user who edited
• Each issue is assigned a unique case number or similar identifier
• The contents of all cases can be easily searched

Practical Example

The entries below come from our FogBugz database.  I documented the problem and solution in a recent article, SSE Setup: Fix for Error -2147024671.

Here's what my thought process looked like in real time:

06/28/2023 11:58 AM

Error creating initial installer (v 6.0.0.0):

06/28/2023 12:16 PM

I keep getting the same error code when trying to sign the installer, so I referred to my article on breaking down Windows error codes and I believe I got to the source of the problem:

Based on this analysis, the digital signature could not be applied because ... something (Windows, Windows Defender, SSE Setup, SignTool.exe, etc.) ... identified some source file as containing a virus.  This has become something of a problem in general, as anti-virus programs use the following two heuristics that are notorious for generating false positives:

• Behavioral analysis (does the code execute arbitrary commands via the command line? If so, it MUST be a virus.  No normal program would ever need to do that [sarcasm]).
• Popularity (this brand new application you are trying to introduce into the world has not been downloaded by thousands of people yet, so it MUST be a virus).

Sigh...

06/28/2023 12:28 PM

Let's pop open Windows Security and check on our Protection History.

Hey, would ya look at that!  A whole bunch of threats found at the exact same times that we tried to generate the installer via SSE Setup. Looks like we found our problem.

06/28/2023 12:57 PM

Looks like we're not the only ones running into this:

Hi
I have developed a Windows app (.exe) in VB with Visual Studio 2019
Compiling it with VS2019 working good but when I run the .exe file I get a Trojan warning from Windows Defender and remove it:
Trojan:Script/Sabsik.FL.A!ml
How to know which the script piece that causing this false Trojan warning by Windows defender.
My software is for internet surfing and using Selenium/chromedriver.exe and it should be distributed to my customers so, adding the .exe file to safe or trusted files doesn’t resolve my issue.
Any help please?
Regards

This is nearly identical to the "threat" found in our application:

Trojan:Win32/Sabsik.FL.A!ml

Breaking down the malware identifier, we learn the following:

• Malware class: Trojan
• Application type: Win32
• Trojan family: Sabsik
• Identifier: FL.A
• Detection type: ml (Machine Learning)

Here's an article with more information about the machine learning virus detection approach in general: In hot pursuit of elusive threats: AI-driven behavior-based blocking stops attacks in their tracks

Other similar false positive reports:

• 64-bit compiled version runs fine, 32-bit detects a virus

More confirmation that Windows Defender is to blame for the issues we're having:

06/28/2023 1:01 PM

I had to temporarily turn off Real-time protection in the Virus & threat protection settings of Windows Security so that the install file could be created:

Once I did that, the install finished without any errors.

06/28/2023 1:07 PM

Rather than having to turn off realtime protection every time we need to build a new installer, I added an exclusion to Windows Security for the SSEBooster executable, which is used to build new setup files:

This did not work, though, because the process that actually creates the setup files is apparently named SSECreateDist.exe.

Let's try again:

That one didn't work either...

I finally broke out Process Explorer and used the bullseye tool and dropped it on top of the Error dialog box to identify the actual process that was running and creating the files that Windows Defender didn't like:

That one didn't work either!!!!  What the heck!?!?!

Well, we're running out of files to exclude, but let's try the original SSELauncher.exe file:

And...of course that didn't work either.  Ye gods!

06/28/2023 1:43 PM

Now let's check Event Viewer.

Navigate to Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational

Each time I tried to generate a new installer, it triggered errors for the following processes:

• SSECreateDist.exe
• EZSignUtil.exe

06/28/2023 1:45 PM

Time to add another exclusion:

06/28/2023 1:47 PM

We finally got it working!!!!!

Here are the current exclusions.  In the end, I think I'll only need the two that were listed in the Windows Event Viewer.  I'll test that next.

06/28/2023 1:51 PM

In the end, I needed to add the following two Process exceptions to the Exclusions setting of Virus & threat protection:

• C:\Program Files (x86)\SSE Setup 10.4\Internal\EZSignIt\Internal\v2\EZSignUtil.exe
• C:\Program Files (x86)\SSE Setup 10.4\SSECreateDist.exe

Cover image created with Microsoft Designer