Archive for May, 2007


Tuesday, May 29th, 2007


To make it short, I was writing a part of a login script in vbs which collects some version information on some “critical” software, and I was a bit suprised when I saw, that “getfileversion” returns for Cisco Systems VPN Client files (such as ipsecdialer.exe). In this case, this happens, because the data part of it’s VS_FIXEDFILEINFO is not filled out properly (at all), …

… thus you can only rely on the “text based” stringfileinfo’s productfile information.

I was looking for several hours to find a method to obtain those parts with some simple commands or script, but all I could find referred to Visual Basic (not VB Script) or C.
“When I was young”, I wrote an assembly program ( on this page) to read data from VS_FIXEDFILEINFO, so I knew that implement it from the scratch would take some time, so I searched along…

Then I found an excellent site with excellent scripts, such what I needed:

Even more, I found some “comments” which I couldn’t even find it on Microsoft’s site:
Normally there is no VBScript method to return the information that shows when a file is right-clicked, then “Properties” is clicked, and the “Version” tab is selected.
I mean: Come on, Microsoft!?! Sometimes documenting that something cannot be done is better than nothing, at least I wouldn’t try to look for an “all-in-one” vbs command for it.

The script is neatly written and does the job. However, after some consideration, I decided not to put another 16K into the login script (tripling its size) just for read one screwed up application’s version number, I will just rely on the DisplayName value of the registry’s relevant uninstall key’s “DisplayName”, it is currently “Cisco Systems VPN Client” on my system, so extracting the version number out of it would do the job.

Anyway, hats off to JSWare for creating and publishing such a brilliant code sample for obtaining version info from the VS_FIXEDFILEINFO resource.

Nprinter history and comment page

Friday, May 11th, 2007

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:] 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 ““.
  • 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.