Last week, I had a task for fixing a bug related to a library from outside my company.
First of all, I found that we were using its functions in a wrong way so I made some changes to correct it. Of course, the way I fixed it is from a document of the library. It resolved the issue and worked well in my machine. But, it turned out that a few machines had another problem with my changes.
Luckily, we have source code of the library so I was able to look into it to find my mistake. However, I realized that they made a wrong assumption about some values and it caused the problem. Since I had the source code, I fixed the wrong assumption, compiled it and produced one dll file for our project. It was working just fine on my test machine as well as my own pc. Yeap, I have two machines and three monitors at work. 🙂
Anyway, the happy moment didn’t last long though. Our build machine reported that it failed to test its final build with my newly produced dll. Our game couldn’t even start with it but just showed a very simple system error dialog with a strange hexadecimal address.
From my programming experience, I know that this kind of problems could take forever if I just try to solve it by myself. I quickly noticed that I needed someone. Someone knows our project very well and understands my task. Yeah, I asked my lead programmer to help me.
We agreed that the changes I made is the proper way to do my task. The problem was why the dll working in my pc didn’t work in our build machine. We found that the dll didn’t work on his machine either. He was for sure that my machine had something different and it produced the dll having incorrect dependency for the other machines. So, what is it?
It took almost four hours us to find the reason. It was not because my machine is using 64 bits Windows and the build machine is using 32 bits one. It was not because of the project setting for the library. It was not even because I used their static version of project to produce dll. (Another good example why naming is so important. They named the project “static something” but it actually created a dll, “dynamic” linked library.)
When my lead and I almost gave up, I found that my Visual Studio 2005 had all the latest updates and the one in build machine didn’t. It’s just my habit that I runs “Windows Updates” or “Microsoft Updates” every day when I have a short break. This habit had never made any problems until this one happened.
It turned out that one of the security updates for VS2005, KB971090, made the problem. From google, I found that dlls compiled with the security update (KB971090) are not compatible with exe files compiled without it, if the machine which runs the exe doesn’t have the update. To solve this problem, I simply uninstalled it instead of following the long solution which you might want to take if you have the same problem. I should mention that you need to check “View installed updates” in control panel to uninstall it. Yeah, it sucks.
Okay, here is what I’ve learned.
Keep the exactly same build environment with the other programmers including a build machine. Don’t blindly get all updates without checking them.