a Heisenbug?

Drama:

Cast (perhaps to Pun type, huh-huh): 

Ms Visual Studio 2019,

Windows 10 Pro,

Windows' applications installation system,

a 10+ y.o. app in .NET-Framework + WTF sorry, WPF, 

and your (un)humble servant.

 

Written in some flavor of Polish-English.

As the Chicken from one fine cartoon put it, giving his homework to a teacher, "read it and weep." 

LongStoryBoring.Start();

Scene 1

So I was getting this weird error that some configuration (an xml file) for a program was being read correctly when the app was being run from VS (Debug mode), and not when the Release version ran, after being "installed." The first occurence of the issue was on someone else's machine. Frankly, there was too much work to be done elsewhere, and since the licensing part of our program uses some Windows machine id, I decided to make a shortcut. A really simplistic one—if it's her machine, just set her (fixed from now on, which is limiting) part of the configuration and start the app. This is something we should all avoid, but we should also "please the customer." In this case—try our best to keep our software running on their machine, sometimes at all costs. Yes, my bad, I decided to to that. Perhaps with some hope that the issue will magically fix itself. Perhaps after a system update?

But it wasn't my fault, I think, that her (Release, and installed in a kosher way) version started crashing on that error; effectively, as it turned out, always returning a null result of deserialization of that xml file. Since the same software did work earlier on both machines (and two or three others). But again, I went through the pain of installing it on my machine, and added config files from the Debug directory inside my "solution" (the name kills me every time I think of it. "Metaproject" would sound a lot more professional). And—surprise!—it ran with no pain at all. It was getting really mysterious and esotheric, so my first thought was—well, maybe I should ask her about that specific file's access rights, what user account does she usually work with, their privileges etc., in other words—look for differences in our environments. There weren't any that seemed releated to the file properties and to the problem itself. By the way—one similar file was being read without problems. But parsed somewhat differently. Perhaps some conflict in xml-related libraries? (Back then I wasn't aware of some tweak in the .csproj settings in VS—related to xml. I learned that it's there and tried various settings, with no effect whatsoever.) The only obvious difference was our language/locale settings. (Which—by the way—reminds me of old times of translated/localized versions of guh-noo/linux distros, when 3/4 of the messages are still in English, regardless of selecting some other language. I didn't bother using Polish version, mainly because of low quality of translations. Win10 is very similar, but the quality seems higher. If you can say that seemingly random choice of language for window titles, content, menu items etc. has something to do with quality. And if you want low quality, take a look at .NET/C#—and perhaps VB—documentation which is auto-translated; luckily, you can avoid seeing that, unless you're into bad jokes, and read the original version.)

Scene 2

Later in the process, my boss, who is now—by a strange set of circumstances—testing the product, started to have similar problems. I was tempted to do the same workaround for her machine, but tried it earlier on mine—and boom!—I was able to reproduce the error. After some time of try and error and rage etc. I decided to deal with the stuff more systematically. So I added a simple logger to the program, just to have a picture of what happens during its startup. Finally I got it working more or less properly, and what I saw qualifies immediately as some uncontrolled flight over the cuckoo's nest resulting with a head-on with welcome home/sanitarium. I'm a man of culture, afterall. Keep him tied it makes him well, He's getting better can't you tell...

Scene 3

Here is what was happening: the damn thing got the right file in the right path. I copied it there myself, using my white mouse and some commands like copy and paste; or maybe I used the keyboard. I viewed that file in notepad++. It was the file. Yet, the logger inside the catch block is forced to dump the file's contents for me, and it showed some completely different file! But not the random one... In fact, it was an older format of that part of configuration in xml, before I redesigned its corresponding class so that the xml got much simpler and more readable. The old code for that class is absent for some months now if not for over a year... It seems that some clever knucklehead at Microsoft did that on purpose, perhaps with something like "pleasing the customer" in mind. Or enabled such behavior on the level of app installer/setup. Or some knucklehead about 10 years ago did this to that particular installer of our software.

Scene 4

I have to find the place where these friggin' ghost-files are copied. When? By who? What for? For morons that cannot tell where their applications' configuration is, so it's safer to silently make a hidden back-up copy for them? That would seem plausible, given how moronic some users are nowadays, myself (an uneducated developer...) included. But making it so that these "ghost files" are read prior to the existing ones seems just way over my capabilities of understanding stuff and peoples' motives to do stuff. If you can't, don't.

If I were to find the real source of this behavior, I would gladly have the author hanging, tarred and feathered. What a dumbass... Yeah, really.

Epilogue

I changed my view on MS a lot when I started developing this and that in C#/.NET. I parted with Windows for good in around 2000/2001, shortly before XP entered the scene. And since then I have used Linux and really enjoyed it. In 2020 I had to switch to Win10 which—compared to Win9x—is really great. Although it suffers a lot from being designed with moronic users in mind. Various "foolproof" solutions are just unnecessary for me, I can't get rid of them... Ok, I can suffer that. What doesn't kill you, makes you frustrated. But it works, more or less.

I appreciate the "free as in free beer" availability of VS and VS code and C# as a whole, even though I can hardly understand some very finesse pieces of code written by experts, using supercomplicated patterns, attributes etc. Esp. when it comes to web programming which I'm just against, don't ask why. (Perhaps because of incompatibility between browsers and some bad experience with web apps that are supposed to work but are unreliable.)

I'm having some problems with vscode on Linux; I find it funny that they are always related to .NET and omnisharp, somehow C++ and Python extensions are just working nicely, although I didn't have the courage to escape from the Makefile/gcc world in the case of C++ yet. And I hate Python, but it's a convenient. And a lot of guilty pleasure to scratch this or that, use it to get some job done, forget about it and never return. Maybe to cut some code to some new scratchy script.

But with such behavior, I get second thoughts.

Moral

An obvious workaround to the problem of these "ghost files" is to rename the proper ones... and wait for the next crash, but at least I would know where the problem lies. Anyway, thank you whoever gave me the chance to even start the process of squishing of this ugly bug.

There is some chance that I'm the guilty party. I doubt it, I doubt I could do such a thing unknowingly in the code. Perhaps in the installer's setup (a messy and scary-looking file, ca. 150kB, json-like perhaps) but I don't recall any changes to it except for incrementing the version and adding some inner configuration files, two or three, perhaps adding icons and so on. Nothing major.

Proof of the existence of "ghost-files"? Well, the guy formerly responsible for Q&A confirmed that his installation runs—so it seems—with no configuration at all. I mean—the program tries to connect to a database, so it has to get some encrypted connection string and start talking to the db. It does so, and the app is up and running. Unless I strongly want to become religious, I have to state that the needed file is still somewhere.

And guess what—I'm not planning to suffer trying to find it under Windoze, esp. with their absurd idea of typing directly on an open "Start" menu. I'm going to take the damned sd drive out, connect it through USB (2.0 I guess) and just grep through some 100+ Gb of junk under the better OS. Perhaps in 4-5 separate directories, in parallel, to speed things up, starting in C:\ would take too long. But I'm in no hurry anyway.

Yep, done it. And fiercely proud of myself. The guilty thing is (most probably) at 

HomeDir/AppData/Local/VirtualStore/

+ the path of our installed program (with stripped C:\ of course) and some 1-y.o. config files. Why these have the priority when the app reads its config and the whole thing pretends to be reading from one location while in reality it reads from somewhere else—I have no idea. Conclusion—either some ill-designed setup/installer or some tweak inside Windoze may be harmful to your mental health and (the remains of) your faith in human intellect. Please consult some user friendly Gnu/Linux distribution forum.

I'm almost sure this behavior is almost random, after examining the contents of this parasite directory on two other machines. It's different. Hence the strong suspicion that configuration of the installer is not to blame. Some symlinks were found somewhere inside HomeDir/Recent and inside the AppData/Roaming/Microsoft/Windows/Recent, all pointing to the proper file. On other machine these folders do not exist. On mine they're there, with no symlinks.

In Polish we have a beautiful curse that is used to say someone has lost their mind—we say that they switched or exchanged heads with a penis (a dick, to be precise). Nah, doesn't sound right. Read my lips: ktoś tu się z chujem na łby pozamieniał. Pronounce: ktosh too shie z khuy'em na wbee poz-uh-meh-nyaw.

Added: it was Micro$oft who exchanged heads to dicks. VirtualStore. Fsck you, developers x 4. What the fuck...