maques's sparks

This page is to let people know what happened (and what not) in connection with the problem that exhibits when using Nprinter (for NT) on an XP with Novell Client 32. (Eg.: blue screen – DRIVER_IRQL_NOT_LESS_OR_EQUAL)
Here you can also express your comments regarding to this issue.
Since the current status of this issue at Novell is “Closed” (unresolved), please do leave your comment here, to raise the chance of this issue to be fixed.

In “short” (but really…):

• I created “my” webpage on Nprinter on 2004.JUN.07. This is approximately more than a year after I needed to have nprinter on Windows 2000 and XP. Later on I started experiencing this issue on XP machines…
• Time passed, I got mails and I also experienced the problem at other customers too.
• I experienced a problem at a customer, where finally we had to buy some print servers to solve the problem, so I got “pissed off”, then I reported “NWClient 491SP2+PKA – nwsipx32.sys – DRIVER_IRQL_NOT_LESS_OR_EQUAL” to: Novell’s patchfeedback address on: Wednesday, May 24, 2006 11:44 AM (with screenshots and other details)
• Same day I got answer from Earle Wells congratulating on how I detailed the problem and that I should use NDPS.
• After several more letters on the same day, I “achieved” that we’ve reached to: “Good news! Engineering is willing to take a look at a kernel memory dump”
• I sent dump, next day he informed me that they found the bug, but it would be too problematic to fix it and probably would never be fixed. An internal TID was also created, and service request ticket was closed.
• I got several more letters from other “nprinter fan-s” and on 2006 August 17, I contacted my Novell “internal” / “problem-solver” friend to check if there is anything more we could do. Next day he wrote me back, that it is in the “wontfix” category, and he could talk about it in more detail for hours…
• So I called him. As far as I remember, he explained that it is not even clear that this is a nwsipx32 bug (as sometimes it happens in tdi.sys which is XP’s part), and it is low priority and obsolete and so on (which I’ve already known/suspected).
  I also tried to ask what would be the cost of fixing this, but it is not the matter of money. I also got the internal mailing on this, saying:
     > The particular point at which the NULL pointer is being
     > dereferenced is within a Microsoft-supplied TDI compile-
     > time macro, and between the complexity of it & the fact that
     > this is release code with full optimization, its going to take a
     > couple hours of de-compiling the previous instructions to
     > root out what exactly was being referenced that was NULL.
     > After that of course comes “why”.
     > So it’s not something that is a slam-dunk or quickly
     > actionable, which doesn’t bode well for an NWSIPX32
     > issue being observed primarily
• So the same day (2006.AUG.18) I contacted another friend of mine – who is my partner’s brother and working for Microsoft at Seattle -, asking whether there is any bugreport on TDI.SYS [based on: http://support.microsoft.com/kb/829120/en-us] or a patch/beta release of the file.
• Next day I got a negative answer and also a suggestion that I should contact MS support starting from “support.microsoft.com“.
• I answered that I don’t “believe” in having any result of a noname guy opening incident via web support, and even if I would, where to start at all…
• Two days later (AUG.21) he mailed that he don’t really know where to start (and via OEM, VAP, Technet or what other channel) and he will ask around.
• On 22nd, another friend of mine called me. I didn’t have any news on what he is doing lately, but it turned out that he is the Director of Support at Microsoft Hungary…
• He guided me what link should I use to let them have green light on this problem and he called me after he “saw” the incident getting started in their system. Then a hour later a support guy called me, I said I didn’t have much more information, but I made dumps available for them to download.
• We agreed that they should look into dumps only where the BSOD happens in TDI.SYS (and not in NWSIPX32.SYS) as the issue exhibits itself sometimes in TDI.SYS, sometimes in NWSIPX32.SYS
• On 23rd I got called from MS Hun. tech support that they need to escalate the problem to higher level, to debug the dump more thoroughly, and also because this really seems to be a “bug”, not a “support incident”. [id: SRQ060822600811]
• On 24th, I got called saying the dump has been done, and the BSOD is Novell’s fault. I asked more (written) technical data, then later I got a a forwarded mail with also not to much technical information, mainly saying: “… basically the problem is caused by a novell driver that is not compatible to windows xp.”
• Then I replied that I would really need more technical info to be able to “bounce back” the problem to Novell.
• Finally I got a Windebug analysis with some comments.
  The most important was:
  “f88a9dac 805ce794 f8b79298 00000000 00000000 nwsipx32+0x4d3a < ---   Here we see the 3rd party driver loaded - but as we do not have the source code / symbols we cannot see the arguments passing up"
• Then I realized I can also do a windebug analyze, so I downloaded and installed Windebug and some other required tools. I “analyzed” the rest of my dumps and created a very detailed analysis and comparsion on the different dumps.
• On 28th, I forwarded my results to my friend at Novell Hungary.
• On Sep. 1 MS contacted me to ask if they can close the incident.
• I asked my friend at Novell on where are we. He said, his guy is on vacation, so I should hold on.
• Time passed, then on Oct 11, I got an information from Novell that they assigned a priority to the bug. Even very low, but anyting can be higher than “wontfix”…
• On FEB 23, 2007, I got a mail that says the bug is planned to be fixed in 4.91SP5.
  Though I don’t have permission to bugzilla, the link is here, and it’s main content is:
     What                 |Removed         |Added
  ———————————————————————
  Fixed in Milestone|—                     |4.91 SP5
• Beginning of May I was informed that the status of this “issue” is “closed”. Not a “wontfix”, but basically closed without a solution.
• I was also suggested that everyone having this problem should contact Novell and open an incident…

Since I believe it would be harder to convince people to do so I tried to support my already opened incident with the dozens of mails I received relating to this issue and I still would like your comment and some data (number of computers affected, maybe company name). The email field at the comment will not be published, so feel free to use your valid address if you would like to be notified upon any advancement.