home *** CD-ROM | disk | FTP | other *** search
/ High Voltage Shareware / high1.zip / high1 / DIR13 / DOSUP8.ZIP / BSD.TXT next >
Text File  |  1993-11-03  |  17KB  |  434 lines
  1.  
  2.               NOVELL TECHNICAL INFORMATION DOCUMENT
  3.  
  4. TITLE:              Black Screen of Death and Other Windows Hangs
  5. NOVELL PRODUCT and VERSION:        NetWare Client for DOS/Windows
  6.  
  7. ABSTRACT:
  8. These files fix a problem when using Windows or Windows for
  9. WorkGroups on a network.  The symptom is a blinking underlined
  10. curser in the upper-left-hand corner of the screen when entering a
  11. DOS box or DOS application and the workstation hangs.  Also covers
  12. symptoms similar to those listed above that may result in an
  13. "invalid opcode" or other windows hanging symptom.
  14. _________________________________________________________________
  15.  
  16. DISCLAIMER
  17. THE ORIGIN OF THIS INFORMATION MAY BE INTERNAL OR EXTERNAL TO
  18. NOVELL.  NOVELL MAKES EVERY EFFORT WITHIN ITS MEANS TO VERIFY THIS
  19. INFORMATION.  HOWEVER, THE INFORMATION PROVIDED IN THIS DOCUMENT IS
  20. FOR YOUR INFORMATION ONLY.  NOVELL MAKES NO EXPLICIT OR IMPLIED
  21. CLAIMS TO THE VALIDITY OF THIS INFORMATION.
  22. _________________________________________________________________
  23.  
  24. ADDITIONAL CONFIGURATION
  25.  
  26. Third-Party Product and Version:
  27.  
  28. Windows
  29. Windows for WorkGroups
  30.  
  31.  
  32. SYMPTOM
  33.  
  34. When entering a DOS box or application, the only thing that appears
  35. on screen is a blinking underlined curser in the upper-left-hand
  36. corner and the workstation hangs.
  37.  
  38. Other various symptoms, manifest as a "windows hang" not inclusive
  39. under the "Black Screen of Death" description.
  40.  
  41. CAUSE
  42.  
  43. Windows has a bug in the WIN386.EXE that is being addressed by
  44. VTDA.386 obtainable from Microsoft.  Their BBS number is
  45. 206-936-6735 and the file to down load is WW0863.EXE.
  46.  
  47. CAUSE
  48.  
  49. IPXODI.COM had a bug in SPX.  During a retry, SPX would jump to
  50. invalid memory causing an invalid opcode exception in v86 mode only
  51. when SPX is being used.  Few applications use SPX.  This usually
  52. manifests itself as a reboot, hung machine, or blank screen with
  53. cursor in upper-left corner.
  54.  
  55. CAUSE
  56.  
  57. LSL.COM had a bug that was GetStackECBPrescanIsPresent destroyed
  58. the return Flag when an ECB was given.  The symptom of this problem
  59. would most likely manifest it self by a workstation hang when using
  60. a protocol stack that expects to get an ECB from the LSL under a
  61. heavy load.
  62.  
  63. CAUSE
  64.  
  65. LSL.COM also had a problem with the "Do Send for Windows" code that
  66. needed a "Start and End Critical Section" call added.
  67.  
  68. CAUSE
  69.  
  70. An incorrect system configuration including memory management.
  71.  
  72. CAUSE
  73.  
  74. Any I/O, memory, or IRQ conflicts may cause this problem.
  75.  
  76. CAUSE
  77.  
  78. Using third-party device drivers or terminate-and-stay-resident
  79. (TSR) programs.
  80.  
  81. CAUSE
  82.  
  83. VIPX.386 is a Windows 3.X virtualization driver for IPXODI.COM
  84. driver that was enhanced jointly by Novell and Microsoft.  It
  85. virtualizes requests to the globally loaded IPX driver.  When a
  86. request is made to IPX, VIPX will allocate a request buffer in the
  87. system's global memory, copy the original request to the global
  88. buffer and give the global request to IPX.  When the global request
  89. completes, IPX will call VIPX.  VIPX will then copy any results
  90. back to the original request buffer and call the application that
  91. submitted the request.
  92.  
  93.  Version Compatibility with Dedicated IPX
  94.  ----------------------------------------
  95. Novell officially ceased maintenance on the dedicated IPX driver
  96. (IPX.OBJ) version 3.10 dated 11-21-91.  The last version of VIPX to
  97. explicitly support that driver is 1.10.  The current version of
  98. VIPX supports IPXODI.COM only.
  99.  
  100.  Packet Size Limitations
  101.  -----------------------
  102. VIPX.386 will only virtualize packets that are 8000 (decimal) bytes
  103. or less.  Any DOS and Windows IPX or SPX applications that use
  104. networks with a physical packet size greater than 8000 bytes may
  105. not work with VIPX.386.  For example, IBM Token Ring can be
  106. configured to run with 16 KB packets.  A request by a DOS or
  107. Windows IPX application to send a 16 KB packet will be truncated to
  108. 8000 bytes.  On the other hand, any 16 KB packet that is received
  109. by the LAN driver will be dropped because VIPX cannot allocate a
  110. packet big enough to handle it.
  111.  
  112.  Memory Manager Limitations
  113.  --------------------------
  114. When a request is passed up from IPX, VIPX will immediately test
  115. the request buffer to see if it is in global memory.  If it is in
  116. global memory, the request will be passed back down to IPX without
  117. any virtualization.  For example, a TSR loaded before Windows is
  118. considered to be in global memory.  If that TSR calls IPX, VIPX
  119. will test the requests and pass them back down to IPX.  This is
  120. done because there is no need to virtualize requests that are
  121. already global.
  122.  
  123. The use of UMA memory complicates the test for global memory. 
  124. There are two basic scenarios.
  125.  
  126. The first scenario is when a TSR has been loaded high before
  127. Windows was loaded.  In this case, IPX requests will come from
  128. global UMA memory.  VIPX will simply pass these requests back down
  129. to IPX.
  130.  
  131. The second scenario is when a TSR is loaded high in a Windows
  132. DOSBOX.  In this case, IPX requests will come from local UMA
  133. memory.  VIPX will virtualize these requests.
  134.  
  135. Some memory managers test for global UMA memory and will work
  136. properly under both scenarios.  However, other memory managers
  137. exist that do not work properly under Windows.  With these drivers,
  138. all local DOSBOX UMAs look as if they are GLOBAL UMAs.
  139.  
  140. In the case of the second scenario when a TSR calls IPX, VIPX will
  141. test the request buffer and think that it is in global UMA memory
  142. when it is really in LOCAL UMA memory.  As a result, VIPX will pass
  143. a local ECB to IPX without virtualization.  The normal result of
  144. this is a hung machine or data corruption.
  145.  
  146.  
  147. SOLUTION
  148.  
  149. Novell strongly recommends that you update your dedicated IPX
  150. driver with IPXODI.COM v2.12, included in DOSUP8.EXE, when using
  151. versions of VIPX later than 1.10.
  152.  
  153. Because of the problems with LSL.COM, Novell also recommends that
  154. you update your LSL.COM to v2.05.  This version is also available
  155. in
  156. DOSUP8.EXE in the NOVFILES forum of Compuserve.
  157.  
  158. If you are using third-party memory managers and hang, do not load
  159. TSRs using the IPX interface (including IPX itself) high.  Load
  160. then in conventional memory only.
  161.  
  162. Files Needed:     Size     Date      Version  Location
  163.  
  164.     VIPX.386      23855   10-08-93    1.17    WINUP8.EXE
  165.   IPXODI.COM      30247   10-07-93    2.12    DOSUP8.EXE
  166.      LSL.COM      17805   09-10-93    2.05    DOSUP8.EXE
  167.  
  168.  
  169. Installation Instructions:
  170.  
  171. 1. Rename or backup the old VIPX.386, IPXODI.COM, and LSL.COM
  172. files.
  173.  
  174. 2. Copy IPXODI.COM and LSL.COM to where the network board's
  175. software is initialized.
  176.  
  177. 3. Copy VIPX.386 to your WINDOWS\SYSTEM directory.
  178.  
  179. 4. Virtualize the network board's IRQ in the [VIPX] section of the
  180. SYSTEM.INI if using IBM LAN SUPPORT.
  181.  
  182. 5. Put TimerCriticalSection=10000 in the [386Enh] section of the
  183. SYSTEM.INI.
  184.  
  185. 6. Reboot the machine and load the ODI drivers.
  186.  
  187. 7. Enter Windows.
  188.  
  189.  
  190. Solution Specifics:
  191.  
  192.  Specialized Configuration Parameters
  193.  ------------------------------------
  194.  
  195. Under most circumstances, VIPX will work fine under the default
  196. configuration.  However, there may be some applications that
  197. require custom configuration of the driver.  This following is a
  198. list of SYSTEM.INI parameters that can be used to configure VIPX:
  199.  
  200. [VIPX]
  201. VipxMappingPages          =[number of 4K pages]  (default = 16)
  202. VipxFailOverSizedPackets  =[ON|OFF|TRUE|FALSE]   (default = OFF)
  203. VirtualizeIrq[0-F]        =[ON|OFF|TRUE|FALSE]   (default = OFF)
  204.  
  205. VIPX Parameters
  206.  
  207.  VipxMappingPages
  208.  ----------------
  209. This is the number of pages that VIPX can use to globalize requests
  210. to the global IPXODI.COM driver.  VIPX is not absolutely guaranteed
  211. to have all of these pages available at any one point, because this
  212. is the requested number of pages for shared global mapping that
  213. VIPX makes to the Windows VMM at initialization time.
  214.  
  215.  VipxFailOverSizedPackets
  216.  ------------------------
  217. This parameter tells VIPX to fail any requests that require more
  218. than the maximum allowed globalization size.  The actual maximum
  219. will vary according to the media the user is using.  The absolute
  220. maximum is 8000 (decimal) bytes.  With media that have smaller
  221. packets than 8000 bytes, the maximum allowed size is the maximum
  222. packet size that can be put onto the media.
  223.  
  224.  VirtualizeIrq[0-F]
  225.  ------------------
  226. VIPX v1.15 or greater avoids a deadlock between the machine and
  227. network board by virtualizing the network board's IRQ.  With ODI
  228. and dedicated IPX (IPX.OBJ) drivers, VIPX will automatically read
  229. the configuration of the network board from the driver and
  230. virtualize the selected IRQs.  However, when using the IBM LAN
  231. Support Program with SLANSUP.OBJ or LANSUP.COM, the LAN IRQ is not
  232. readable from the driver.  The only way to get this information is
  233. to read the network board hardware itself.  The problem with doing
  234. this is that the hardware can be Token Ring, PCN2 or Ethernet. 
  235. VIPX must now be aware of many different hardware configurations. 
  236. Instead of this, VIPX requires the IBM LAN Support user to specify
  237. the network board's IRQ in the [VIPX] section of the SYSTEM.INI. 
  238. IRQs range from 0 to F (hex).  An example is listed below:
  239.  
  240.      [VIPX]
  241.      VirtualizeIrq2=TRUE
  242.      VirtualizeIrq3=TRUE
  243.  
  244. In this example, VIPX will virtualize both IRQ 2 and IRQ 3. VIPX
  245. can virtualize up to four different LAN IRQs.  The reason for
  246. virtualizing multiple IRQs is to allow other LAN boards and
  247. protocols to be installed on the same PC and prevent them from
  248. deadlocking the machine.  For example, you may have IPX running
  249. through an NE2000 board on IRQ 3 and TCP/IP running through to an
  250. IBM Token-Ring board on IRQ 2.
  251.  
  252.  TimerCriticalSection
  253.  --------------------
  254. As of version 1.15 of VIPX, TimerCriticalSection is required to be
  255. set on.  The recommended setting is as follows:
  256.  
  257.      [386Enh]
  258.      TimerCriticalSection=10000
  259.  
  260. The reason for this parameter is to avoid a deadlock with the LAN
  261. IRQ Virtualization code.  See "VirtualizeIrq[0-F]" section.
  262.  
  263. Changes to LSL.COM v2.05
  264.  
  265. 1. GetStackECBPrescanIsPresent destroyed the return Flag when an
  266. ECB was given.  The symptom of this problem would most likely
  267. manifest it self by a workstation hang when using a protocol stack
  268. that expects to get an ECB from the LSL under a heavy load.
  269.  
  270. 2. Added a line to correct ECBLISTHEAD overwriting of variable
  271. StackECBHoldQHead.
  272.  
  273. Changes to LSL.COM v2.02
  274.  
  275. 1. Commandline Switches:
  276.  
  277. Valid switches:  U, F, ?, H, C=
  278.  
  279. Only the "U, ?, C=" are documented in the help.
  280.  
  281. U    Used to unload LSL.
  282.  
  283. ?    Used for Help.
  284.  
  285. F    Used to force the unload.
  286.  
  287. H    Used as an equivalent to "?" switch, and is used by
  288.      many of Novell's other utilities.
  289.  
  290. C=   Used to change the path or filename of the configuration
  291.      file. The "C=" switch is the only two-letter switch that is
  292.      valid,  Custom Configuration Files.  When using the "C="
  293.      command-line switch, the LSL first tries the
  294.      [path]\filename as given.  If the file is not found, then
  295.      the filename is searched for in the directory where the LSL
  296.      was loaded from; and if it still cannot be found, it looks
  297.      in the current working directory.  If all these efforts
  298.      fail, then the LSL reverts back to looking for a "NET.CFG"
  299.      file in the directory where the LSL was loaded from then in
  300.      the current working directory.  The filename is considered
  301.      valid even if the path was incorrect.  After parsing the
  302.      Configuration file, the  LSL displays the relative path of
  303.      the Configuration file that was parsed.
  304.  
  305. 2. LSL.COM had a number of bugs and one was a bug that caused a
  306. deadlock situation with the LAN adapter.  A Do Send for Windows
  307. needed a Start and End Critical Section call added.  It is now
  308. language enabled.
  309.  
  310. 3. Multiple Prescan Stack Chaining did not pass a packet properly.
  311.  
  312. 4. GetProtocolControlEntry would not return the DefaultProtocol
  313. Control Entry point if it was not the only stack in the
  314. DefaultProtocolChain.
  315.  
  316. 5. Bound checking was added on the MLID Support Functions.
  317.  
  318. 6. Error code not preserved in Deregister Prescan Tx chain.
  319.  
  320. 7. A bug in Memory Calculation when calculating the amount of
  321. memory to reserve when going TSR was fixed.
  322.  
  323. 8. The LSL, while checking for boards and Protocols that were still
  324. registered would unload from memory, leaving the still registered
  325. entities with bad pointers.  The LSL will now remove all the MLIDS,
  326. through the SHUTDOWN command.  The LSL will not unload if a
  327. Protocol stack is still registered with the LSL.
  328.  
  329. 9. On Installation of a LAN driver, the LSL would check the version
  330. of the Configuration Table and delete the board number.  This is
  331. now fixed.
  332.  
  333. 10. On unload of a LAN driver, the driver called
  334. MLIDSUP_DEREGISTER_MLID, which called MLIDSUP_CONTROL_STACK_FILTER.
  335.  
  336. When testing for board numbers that are bound to the MLID, a JNE
  337. was used where a JE was needed.
  338.  
  339. IPXODI.COM
  340.  
  341. Command line Switches:
  342.  
  343. Valid switches: /?, /D, /A, /C=, /U, /F
  344.  
  345. ?    Used for help screen.
  346.  
  347. D    Used for Eliminate Diagnostic Responder; reduces size
  348.      by 3 KB.
  349.  
  350. A    Used for Eliminate Diagnostic Responder and SPX;
  351.      reduces size by 9 KB.
  352.  
  353.      PLEASE NOTE:  Disabling SPX will mean that SPX
  354.      applications (such as RPRINTER, BTRIEVE, RCONSOLE, or
  355.      Netware for SAA STRNRTR) will not be supported on this
  356.      workstation.
  357.  
  358. C=   Used to change the path or filename of the
  359.      configuration file.  "C=" is the only two letter switch
  360.      that is valid.  If the *.CFG file used does not exist a
  361.      message will be displayed that the standard NET.CFG
  362.      file will be used instead.
  363.  
  364. U    Used to unload.
  365.  
  366. F    Used to force the unload.
  367.  
  368.  IPXODI.COM v2.12 Released for NetWare 4.01 Update
  369.  
  370. 1. Fixed SPX problem that was seen using NASI/NACS modem sharing
  371. data.  This problem shows up when using an SPX applications that is
  372. transferring data in full duplex mode (most SPX applications do not
  373. do this).  The code was advancing the session sequence number in
  374. the local session table immediately after sending an SPX data
  375. packet to the other side.  If a data packet came in from the other
  376. side that did not acknowledge Novell's "send," Novell would
  377. generate a system packet back to the other end with the session
  378. sequence number set to the value in the local session table, which
  379. is one higher than what it should be.  Then if Novell's data packet
  380. got dropped, Novell would retransmit it, in which case the other
  381. end would ignore our packet since it session sequence number was
  382. not high enough.  This would result in session failure.
  383.  
  384. 2. Enhanced initialization code to check the board's node ID for
  385. all 0FFs.  If it is then we display an error and fail to load. 
  386. This enhancement was requested by Novell Austin for support of his
  387. serial line ODI drivers which set the node Id to all 0FFs if the
  388. user hasn't made a connection.  A new error message has been
  389. created for this condition, however the code checks to see if the
  390. msg file IPXODI is using has the new error message.  If it does
  391. not, then the error condition is ignored and IPXODI still loads. 
  392. This will allow current/older msg files to be used successfully.
  393.  
  394. 3. A problem in RxHandler was fixed that was introduced in IPXODI
  395. v2.00 where in the case Novell steals a mapping ECB then they have
  396. to have VIPX get a client receive ECB.  Novell was not preserving
  397. register AX, which was supposed to have the destination socket
  398. number.  In this case, VIPX would return that there was not any
  399. receive ECB since it thought the socket was not opened when in
  400. reality it was and it had receives posted.  This bug can cause
  401. back-to-back receive packets to be dropped when the packets are
  402. destined for an IPX application (DOS or Windows) running under
  403. Enhanced mode Windows.
  404.  
  405. 4. Novell fixed IPX diagnostic responder code so it would return a
  406. 0FFFFh in the SPX socket number field of the IPX diagnostic query
  407. reply packet when SPX or diagnostic portion of IPXODI has not be
  408. loaded by the user.  This provides a method for diagnostic
  409. applications to determine if SPX is there or not so they do not
  410. have to attempt a SPX connect request if SPX is not there.
  411.  
  412.  IPXODI.COM 04-23-93 v2.11 Released for NMS and NetWare 4.01 
  413.  Release
  414.  
  415. 1. Implemented fix in SPX.ASM SPXConnectHandler routine where it
  416. was not preserving the session count in CX when comparing the
  417. session addresses.  This problem exists in the dedicated IPX/SPX
  418. module as well.  To see this problem the same source connection ID
  419. would have to be in use by two nodes trying to connect to a
  420. particular node.
  421.  
  422. 2. Novell fixed a bug in SPXMessageHandler routine where it was
  423. setting the a send ECB's ESR to SessionSendCompletedDelayed without
  424. a group "CGroup:" override that caused a bogus offset to be put in
  425. the ESR offset field.  Thus when the active send finished it would
  426. blow up.  This problem exists in the dedicated IPX/SPX module as
  427. well.  This problem showed itself while running the Novell NMS
  428. Windows application for a few hours.
  429.  
  430. 3. IPXODI.COM had a bug in SPX.  During a retry, SPX would jump to
  431. invalid memory causing an invalid opcode exception in v86 mode only
  432. when SPX is being used.  Few applications use SPX.  This usually
  433. manifests itself as a reboot, hung machine, or blank screen with
  434. cursor in upper-left corner.