Debugging

Written Rubberducking: A Practical Example

A practical example of the written rubberducking technique taken straight from our FogBugz issue tracking software.

Mike Wolfe

Jul 6, 2023 • 6 min read

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: