Has anyone seen a GUID fail?

I have a really puzzling problem with a program that works on many computers. On one particular computer, the user is reporting behavior that makes no sense. I've studied the code at length, and have these notes: The problem is occuring in an action that is one of the most common actions taken in this program, so if it was a common problem, then I would have seen it years ago. The problem is reported to occur as the result of pressing a certain button, but after repeated stepping through the code, the symptoms can't be triggered by that button. Finally, I did see a way that the reported behavior could occur, but it requires TWO miracles to happen.

What happens is that form is loaded that shows an empty row from a database. There is a button that fills in a textbox with the string "1". The button was added because a button is faster than typing, and the value in that textbox will be 1 for about 95% of all cases. When the user presses that button, the string "1" is put into the textbox, and the background color of the textbox is set to green. After stepping through the code about three times, I have assured myself that nothing else ever happens as a result of this button, except that a textbox is changed, and the background color of the textbox is set to green.

The user is reporting that when they press the button, a totally different row from the datatable is loaded into the form. That seems suggestive, as there is a method called LoadRow that does just that. I therefore confirmed that the row is never called as a result of pressing that button. It IS called earlier, before the form shows, but never as a result of pressing the button.

After a bit more study, I did find some code that would incorrectly load the first row in the datatable, but that code only runs when all reasonable alternatives have been exhausted. Furthermore, it only runs before the user could have any chance to press that foolish button, because it runs before the form is shown. I did force the code to run by altering it so that there were no reasonable alternatives, and it did load the row, as expected, but it happened before the form was shown.

Therefore, I'm at a loss. The one piece of code that could account for the behavior the user is reporting (and a very knowledgeable user, at that) is if an invalid GUID was created, and even then it would require a second miracle, because an invalid GUID would cause aberrant behavior before the time the user reported it.

Still, it's the only thread I've got, so I'm clinging to it until I get more information. It did lead to this question: Has anybody seen a computer that created invalid GUIDs? The GUID type is created by the OS, I believe, and it is based off of a variety of factors including the system date and time, along with the MAC address, among other things. One of the things that has me baffled is that this problem seems to be restricted to one particular computer, so an invalid GUID creator would be one way that a failure could be specific to one particular piece of hardware.

Of course, even if the GUID were invalid, the result would not be what was reported, but for now, it's all I can investigate.

I think the next step should be to create an invalid GUID yourself to confirm identical behavior. I'm very reluctant to consider that the system is generating invalid GUIDs since its such a ubiquitous thing throughout Windows. I mean COM/OLE uses GUIDs extensively though not necessarily generating them but simply reading them and comparing but still. Also, I believed that recent Windows versions from XP maybe even a little farther back stopped using MAC Addresses for creating GUIDs. I found an article a few years back about that. Something about MAC Addresses not being really unique or some such thing, I can't really recall.

Yeah, I'm reluctant about the whole thing. As it turns out, I no longer suspect invalid GUIDs, but the problem is certainly something equally disturbing.

The problem has happened to two different people by now: A particular form is opened. When a button (the exact button was different in both cases) is clicked, a datarow is loaded into the controls. The code behind those buttons has absolutely nothing to do with loading datarows. There is a function that loads a datarow, but that function is not reachable by any correct or incorrect behavior of those buttons. I have confirmed this repeatedly both positively and negatively (seeing what it did do, and confirming what it did not do).

In the most recent case, a very experienced user was there and tried various things, including UNINSTALLING AND REINSTALLING THE PROGRAM. Nothing worked, which is when I got the call...on top of a mountain in a different state, but I still got the call.

In both cases, the person eventually gave up and went home. The next day, when they started the computer, the problem was gone and the program worked perfectly. As I said before, this is a core item in an application that has been used for years by many people, so there is a huge amount of experience with this particular part of the program.

Because they uninstalled and reinstalled, I would say that the people involved with this recent incident have tried everything that they could have from their position. The fact that the program suddenly started working after a re-boot suggests that the issue could not be in the source code, exactly, but lies either in the framework or in the OS itself. With only the two data points, I have very little to go on. However, I have told everybody within reasonable proximity that if they see this happen again they should call me and I will get there as quick as I can to study the problem when it is happening.

When you hear hoofbeats, you should think horses, not zebras. In this case, I have ruled out the horses. I may not be able to isolate the issue, but it is certainly a very strange beast indeed.

Hmmm....what about AddHandler statements. Sometimes one can slip up and forget that certain objects need disposing and can go out of scope and while they are waiting for the GC to clean them up, they can still raise events. The Handles clause automatically unwires events when you set its object variable to Nothing but event handlers attached via AddHandler would still be attached and can still be raised until either you detach them with RemoveHandler or the object is cleaned up by the GC. Check for something like that. That can create some freaky bugs especially with mult-threaded classes or classes with Timers.

AddHandler was not used in the project.

Side effects from handlers running was what I was specifically looking for. However, I was looking on my test system, not the one that had the problem. However, uninstalling and reinstalling the program will most certainly get rid of any errant event handlers. Of course, you might say that the handlers would get added right back in when the program runs again, but keep in mind that this program has been running on many computers for years. In fact, the first gal to report this had been using the program for years and this suddenly began happening. At the time, I studied the problem and ended up finding a totally unrelated bug (though I thought it was related when I found it). For her, the problem was gone the next day and hasn't returned since.

I don't think that anything as simple as an errant handler could account for this behavior. However, the fact that it is so maddeningly intermittent, and appears to fix itself on re-boot, but not re-install, suggests that this has nothing to do with the program itself. The fact that it happens on exactly one form in the program suggests that it most certainly DOES have something to do with the program. However, the further fact that it has happened as a result of two different, and totally unrelated, actions just makes it weirder.

One thing that I am toying with is that the issue isn't really about the controls populating on an unrelated action, but that the controls were populated, but the form hadn't painted correctly to show it. This actually makes more sense, as impossible as it is, because the only code that I have found that could do what people have reported happens prior to the form being shown, and not again. So, if that method is the culprit, then it requires either:

A) The screen didn't paint when all the controls were updated, which is improbable.

2) It was populating, but taking its time for some reason, and not blocking input, which is also improbable, though not strictly impossible.

I have to get my hands on it to test those alternatives.

Hmmm...well I'm fresh outta ideas :(

I experienced this with a long running program I have as well. I was content to simply rewrite it rather than go digging around in its code which was by then quite unfamiliar to me.

Experienced what? How close was your experience to what I described? That could be interesting.

Well, I have a client/server program that's responsible for providing auto update capabilities to VB6 programs. It worked great for years but all of a sudden, its transfer rates have gone down to like 100 Bytes per second and I haven't change this code in about a year. I know its not our internet, so it has to be the a bug in the software. Well that program has been such a patch job from the beginning so I wasn't really surprised. I can't even begin to guess why its malfunctioning all of a sudden. Being that the program is such a hack job, I really didn't want to go back in there to try and diagnose this. I'm sure I'd be in the same boat you are in now with your problem so I opted to re-write instead. As a matter of fact its what I'm working on now. I've never been good with these types of "ghost in the machine" type of problems. Thank God I don't experience them too often.

I'm not quite there. In my case, the possible sources for the problems are very few, and can generally be tracked down.

Quote:

---

When you hear hoofbeats, you should think horses, not zebras.

---

Well that's your problem. Horses and Zebras are notoriously bad at typing due to their big clumpy hooves and expecting them to use a mouse is equally unreasonable. They're probably hitting the wrong button by accident.

I think you're only real chance in a situation like this is to replicate the problem, and that's going to be easier said than done. From what you're saying, though, it sounds like once the problem starts happening it keeps happening, that'll help.

Try sitting and watching them if you can (not easy from the side of a mountain, I apreciate), just to make sure they're not doing something unexpected (even experienced user'll surprise you from time to time). It'll also help you to replicate the problem later beause you'll be able to work in the same way they do (e.g. using shortcut keys etc).

Set up an enviroment as close to theirs as you possibly can and thrash the hell out of it until the problem occurs. I've even got to the point of temporarily installing an IDE on a clients machine before now.

Temporarily chucking some trace code in that writes to a log file you can interrogate later can help. If you're relationship with the client is good enough you can even put pop up message boxes in.

There's no shortcut through any of this and I'm probably not telling you anything you don't already know so apologies if I'm teaching you to suck eggs but I'd be more suspicious of the code than I would the operating system.

All good points, especially about the inability of horses and zebras to type coherently.

When you have a problem that happens on one form in one program, how can it be anything other than the code? However, when you have a problem that goes away when the computer is re-started, but not when the program itself is removed and re-installed (which is the most extreme form of restarting possible), how can it be the code iteself, when the program is running fine on dozens of other systems, and has for years?

The key problem is that I can't reproduce any of this. In four years on dozens of systems, this issue has happened exactly twice. Interestingly, those two times were only a few months apart, which might be suggestive in itself (partly because the people who are using this have all been moving to Win7 systems in the same time window). I can't very well set up a system and thrash it till it exhibits the problem, because statistically speaking, that would take a couple years. What I do want to do is see the problem in action. The first time it happened, I kind of shrugged. The most recent time, I was a solid 12 hour drive away from the location where it was occuring, so traveling was out of the question (I did ask the user to hang onto the issue, but they had already re-booted, and the problem had gone away). Now that I know it is an issue, I will try to get a look at it in person, as there are several points of interest to examine, but when will that be? In the meantime, all I can do is review the code and post futile threads like this one.

Quote:

---

I was a solid 12 hour drive away from the location where it was occuring, so traveling was out of the question

---

pfft, lack of commitment.:rolleyes:

Quote:

---

The key problem is that I can't reproduce any of this.

---

OK, waxing philsophical for bit: if it's that rare is it worth fixing. Especially since it sounds like it's an ancillary function that's really just a "nice to have" rather than a necessity for the system to operate. If it's only going to happen twice in the next four years then you can probably just ignore it. If, on the other hand, the underlying tech has changed and you're going to start seeing it alot then it's definitely worth fixing, but then it won't be as difficult to replicate either.

I guess my advice would be to hang fire for a bit and see how many more instances you get. From what you've described it sounds like you probably are going to see a few more instances but you should also be able to gather some extra information that might help you solve it. With the info you've got currently you really are reduced to reviewing the code and posting futile threads which is probably not a particularly good use of your time (which could be more productively spent arguing about orcas). When something like this comes up having a quick code review is a good idea but if you haven't spotted the problem in the first hour or so you're just not going to. Instead you'll just end up reading the same few lines of code again and again to no avail. Don't let this become your whale, Ahab.

Besides, there haven't been anywhere near enough cheese based puns in CC lately.

Two words: The user ...

Something I've noticed: when you ask a user what they just did, or how they do their job... you get the steps 1,2,3,4,5.... BUT if you were to observe them, you'd find out that it's more like 1,2,A,3,B,4,C,D,E,5 ... there is always a a couple steps that they inherently do that they don't realize... it's so automatic that they may not realize they are doing it.

-tg

Quote:

---

Originally Posted by techgnome

...when you ask a user what they just did, or how they do their job... you get the steps 1,2,3,4,5.... BUT if you were to observe them, you'd find out that it's more like 1,2,A,3,B,4,C,D,E,5...

---

This is so so true.

Quote:

---

Originally Posted by FunkyDexter

I guess my advice would be to hang fire for a bit and see how many more instances you get.

---

[Dripping Sarcasm]
Considering that I can't either replicate the problem or fix it, I think I'll just take that advice.
[/Dripping Sarcasm]

The reason I want to deal with this is because it is so bloody fascinating. Based on what little information I have gathered to date, this is either going to be a fantasically weird bug in the code, or it is going to turn out to be in either the OS or a 3rd party control. Any of those would make my day, so why the heck wouldn't I pursue it? A bug of such sublime beauty as this one appears to have is like the calls of the sirens: The sailors may have died on the rocks, but you have to remember that they WANTED to at the time.

This is a good read to send to people that are reporting bugs to you. Most people don't realise how incomplete their bug reports really are.

Quote:

---

Originally Posted by techgnome

Two words: The user ...

Something I've noticed: when you ask a user what they just did, or how they do their job... you get the steps 1,2,3,4,5.... BUT if you were to observe them, you'd find out that it's more like 1,2,A,3,B,4,C,D,E,5 ... there is always a a couple steps that they inherently do that they don't realize... it's so automatic that they may not realize they are doing it.

-tg

---

That's certainly true. I was a long ways away (by both boat and car) at the time of the last incident, so there was little I could do. However, I am heating the iron and getting ready to more properly question the user. Unfortunately, the person who reported this was the single most knowledgeable person involved with this project in any way other than me (and in many ways he knows FAR more about it, though not about the coding itself). If anybody was capable of making a good observation, it would be him, so I really only expect to clarify a few things with him rather than getting anything else of critical importance.

Ultimately, what you state is the very reason why I want to see this in practice. It won't happen in the development system (where I have tried that code hundreds of times), and seeing it in person doesn't give me as much information as it would in the dev system, but it would allow me to be certain that proper steps were followed on a re-installation of the program, which should narrow down the possible sources for the problem.