Windows NT 4.0 service pack issues??


Thread Starter

Jansen, Joe

Hi All!

I have an application that I wrote in VB 6.0 that reads data from a SLC 5/05 via ethernet using a purchased component, and stores it into a SQL database. Polling speed is 1 read every 1/2 second.

This app runs flawlessly on Windows 98 first edition. When I try to move it to a machine running Windows NT Server 4.0 with service pack 6, it will only run for about 4-6 hours, and I get a Dr. Watson fault.

Has anyone heard of problems with SP6? The reason I ask is that I often hear of people still using SP5, and was concerned that there may be a reason for that.

If anyone wants to contact me offlist, I can provide Dr. Watson logfiles, source code, etc. the component vendor says that they have run their ActiveX for 'years' without any problems under NT 4.0 server. He did try setting up a demo in their shop using my source code, and did not have any problems.

Thanks to all!!

--Joe Jansen

Carlos Araya Mackenney

I had problems with V.B some times moving programs from Windows to Windows NT. The solution I find is generate the EXE again in the same operating system that the software will run.
Good luck!!

Carlos Araya Mackenney [[email protected]]
Automation Manager - PLC International S.A.
Telephone (562) 269.8727 - Fax (562) 269.8728
Santiago, Chile

Dave Ferguson

I have been using 6.0a service pack with no issues for the last couple months.

Dave Ferguson
Blandin Paper Company
DAVCO Automation
SP6 had some problems which were fixed in SP6a , I believe the most current and stable service pack .

Gladys Díaz

Do you know if this problem happens with VB5 too?. My problem is so serious. An application works in background, i generate it with Windows 95 and when i pass it to windows NT 4.0 with SP6 ... Surprise ... Dr. Watson. It important say that the pointers (memory) are handled in VB in independent way .. i.e. you don´t have the control over them like C++ or others...

If you know something about it, I would thank you so much.

Thanks in Advance.


John Wheatley

Did you rerun SP6 after installing any new NT services? We have been surprized by installing a new service after running SP6. Solution is to rerun SP6 after all installs. Just a thought.
This appears to have been solved by installing VB on the server on recompiling on NT Server. Even when I compiled under NT Workstation 4.0, it had the same problem. My only concern now is that I *really* don't like doing any development work on a on-line server, but can't justify setting up a seperate machine just for doing compiles. I guess I can always multi-boot, it's just rather annoying.

Thanks for all the help from everyone.

--Joe Jansen
What you are experiencing is what is commonly known as "DLL hell". Once you compile an application on a specific platform (i.e. Win 95, Win 98 or Win NT) that's it, your application will only run reliably on the platform it was compiled on. As software developers we face this problem on a continual basis, Microsoft is contently changing the underlying DLL's that are used to provide operating system functions. Many articles have been written on DLL hell and its accompanying problems, unfortunately your options in this type of situation are limited. Here are some of the ways we work around the problem.

1.) Use Linux when possible.
2.) When option one is not available, always apply the latest service packs to Microsoft service packs in the following order. Uninstall the service pack as recommended by Microsoft (don't de-install lower than service pack 3 for NT), install your new software and then reapply the latest Microsoft operating system service pack. This will ensure that the newest DLL's are available for your application.
3.) When developing software try and use individual machine for compiling and testing, currently we have three machines for this purpose Win NT, Win 95, Win 98.
4.) Try and use Win NT 4.0 instead of Win 95 or 98. Win NT 4.0 is the most stable of all three and will give you the best long-term results. Win 95, & 98 are nothing more than complete crap.
5.) Always install the latest visual studio service packs, currently at SP4. Microsoft is constantly applying Band-Aids to its products, make sure you have the latest.
6.) If possible subscribe to the Visual Basic magazines, they are constantly addressing the DLL issues with positive results.

Remember you are not alone, the problems you have described are quite common and are purely Microsoft issues. Hope this helps.


Mark Rohn