We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you two Citrix podcasts. Learn about 2020 trends and get answers to your biggest Citrix questions!Listen Now


missing vshare, ebios, ndis2sup.vxd

russ1 asked
Medium Priority
Last Modified: 2013-12-16
Occasionally when I boot up Win95 I run the bootlog...
I took the time to look at it the other day and I find
a "loadfail" message for these 3 drivers and in this order:
ndis2sup.vxd, vshare, ebios...

Of these drivers only ndis2sup.vxd in on my harddrives...
Any ideas if vshare and ebios are necessary and if so how
can I replace them?
Watch Question

In you system.ini you should have a entry below:
If not add that. vshare is the equal to the old share.exe.
also look in your registry,
at: you should have vshare.vxd here.
They are helpful in some instances where sharing is required, but not vital.

Also, if you feel you need them,( \They are on your 95 CD), mine are not loaded either. You can extract then from your CD to
C:\windows\system like this:
To extract from CD, 1st Change Directories to the X:\WIN95> prompt, where X is your
CD-ROM's drive letter. Then type the following:
EXTRACT /A /L C:\Windows\System WIN95_02.CAB vshare.vxd
EXTRACT /A /L C:\Windows\System WIN95_02.CAB ebios.vxd.
If you are not having problems and 95 is running smoothly you don't need them. They are Virtual device drivers:
To get a good understanding of VXD's go to:

If this does not answer you to your satisfaction, comment back to me and I'll go in more depth

Sorry about the multible answers, I'm having trouble with my ISP dropping me today???
The reason that you see the ebios and vshare failing in bootlog is that there are prbably references to them in you registry, they are seen and 95 trys to load them but can't because as you said, they are not on your HD.
This should help:
Load Failures Listed in the Bootlog.txt File

Last reviewed: April 28, 1997
Article ID: Q127970
The information in this article applies to:

Microsoft Windows 95


When you review the Bootlog.txt file in the root folder
on your hard disk, you may see the following lines even though
your computer seems to function properly:

LoadFailed = dsound.vxd
LoadFailed = ebios
LoadFailed = ndis2sup.vxd
LoadFailed = vpowerd
LoadFailed = vserver.vxd
LoadFailed = vshare
InitCompleteFailed = SDVXD


These load failures do not necessarily mean that there is a
problem. It is common for some, if not all, of these to fail,
depending on your system configuration.


Many sound drivers are DirectSound enabled. DirectSound is
part of Microsoft DirectX, a set of libraries used by most
newer Windows-based games. When a DirectSound-enabled sound
driver is loaded, it attempts to register with the
DirectSound library so that games can use it. If no DirectX-based
games are installed on your computer, the DirectSound
library fails to load. This is normal.


The extended BIOS driver did not find an extended BIOS, so it
does not load.


The NDIS 2 support driver did not find any NDIS 2 drivers to
support, so it does not load.


The Advanced Power Management (APM) driver determined that your
computer does not support APM, so it does not
load, or APM support may be disabled. To determine if you have
inadvertently disabled APM in Device Manager,
follow these steps:

1.In Control Panel, double-click System.

2.Click the Device Manager tab.

3.Double-click the System Devices branch to expand it.

4.Double-click the Advanced Power Management Support branch.
(If this branch does not exist,
your computer does not support APM.)

5.Click the Settings tab.

6.Verify that the Enable Power Management Support check box
is selected.


Vserver.vxd does not load statically so that it can save
memory by loading later in the boot process only if it is needed.
For example, Vserver.vxd might not be needed when you start a
laptop computer while it is out of its docking station.


If you examine the Bootlog.txt file, you will notice that
VSHARE loaded successfully earlier in the boot process. The
second copy of VSHARE detects that VSHARE is already loaded
 and does not load.

Font Failures

After the first boot of Windows 95, the Bootlog.txt file may
list many font load failures. This is a normal occurrence.
When Font Manager searches the hard disk for fonts, it may
find them in several folders. After it finds them, it records
the information so that future attempts to locate a font proceed
more quickly.


Windows 95 automatically loads a miniature disk cache to
increase the speed of the boot process. When the boot process
is complete, the miniature disk cache is unloaded from memory.
When it is unloaded, the above line is added to the
Bootlog.txt file to indicate that the miniature disk cache has
been removed from memory.

This is normal behavior.


smeebud's answer is something I already tried but it failed to
work for me...

Smeebud correctly points out where it is located in the registry
but the files ebios.vxd and vshare.vxd are still not there (why should they be when I couldn't locate them the 1st time?) and the file ndis2sup.vxd still apparently will not load if what bootlog reports is accurate...

Does anyone know if the files vshare.vxd and ebios.vxd are located in one of the "cab" files on the Win95 install cd?

thank you

biosxlat.vxd : Starts in cabinet win95_03.cab on disk '3'
cdfs.vxd : Starts in cabinet win95_03.cab on disk '3'
08-24-1996 11:11:10a A---        17,993 ebios.vxd
I did point that out, at least how to exstrct them
 Cabinet WIN95_07.CAB
08-24-1996 11:11:10a A---        14,926 vshare.vxd

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts

For 4.00.950
 Cabinet WIN95_03.CAB
07-11-1995  9:50:00a A---        17,993 ebios.vxd
 Starts in cabinet win95_04.cab on disk '4'
07-11-1995  9:50:00a A---        14,926 vshare.vxd

Explanation of Ebios:
12 The EBIOS: translation

Contents of this section

12.1 Why translation?

Both the 'int13' software interface used by the BIOS to communicate with
the outside and the Cylinder/Head/Sector (CHS)
fields in the partition table reserve

10 bits for the cylinder field, for a total of up to 1024
8 bits for the head field, good for up to 256 heads;
6 bits for the sector field, which gives a maximum of 63 sectors
since for historic reasons the sector field starts at sector
1, not 0.

The maximum disk capacity accessible through the traditional int13
interface is therefore 8GB (1024*256*63 sectors of 512
bytes). In some books, you may encounter references to 12-bit cylinder
numbers; this extension (using the upper two bits of
the sector field) was never widely implemented and isn't supported

Now IDE disks have their own set of limitations; these disks, no matter
if they're ATA/IDE or ATA-2/EIDE, use

16 bits for the cylinder field, giving 65536 cylinders;
4 bits for the head field, or only 16 heads at most;
6 bits for the sector field, just like the BIOS.

This is good for a maximum disk capacity of 128GB. However, combine this
with the BIOS limitations and you suddenly can't
see more than the first 1024 cylinders of the IDE disk, which makes for
a limit of just 504MB or 528 million bytes. This is
unacceptable today. In the long term, the BIOS limit of 8GB is just as
unacceptable, but as a short term solution it is desirable
to get the maximum out of the standard int13 interface with IDE drives.
This is where translation comes in.

12.2 How does translation work?

There are roughly three ways today's BIOSes can handle translation:
standard CHS addressing, Extended CHS addressing,
and LBA addressing. Translation does NOT automatically imply LBA, as you
will see.

Standard CHS: no translation at all :-(

Communication between drive, BIOS and operating system goes like

 +-------- DRIVE --------+    +- BIOS --+    +---- OS ----+
 |                       |    |         |    |   & APPS   |
 |   physical      T1   logical        logical            |
 | geometry used  ====> geometry ----> geometry           |
 |internally only        (CHS)           (CHS)            |
 |                       |    |         |    |            |
 +-----------------------+    +---------+    +------------+

There is only one translation step, T1, which is internal to the
drive ('universal translation'). The drive's actual, physical
geometry is completely invisible from the outside---the Cylinders,
Heads and Sectors printed on the label for use in the
BIOS setup have nothing to do with the physical geometry! The
logical geometry, used throughout, is subject to both
IDE's limitation to 16 heads and to the BIOS' limitation of 1024
cylinders, which gives the (in)famous 504MB limitation.

Extended CHS

 +-------- DRIVE --------+    +- BIOS --+    +---- OS ----+
 |                       |    |         |    |   & APPS   |
 |   physical      T1   logical   T2  translated          |
 | geometry used  ====> geometry ====> geometry           |
 |internally only        (CHS)           (CHS)            |
 |                       |    |         |    |            |
 +-----------------------+    +---------+    +------------+

Logical geometry is used to communicate between the drive and the
BIOS, while a different, translated geometry is
used to communicate between the BIOS and everything else.

There is an additional translation step, T2, performed by the BIOS.
This procedure breaks the 504MB barrier because
the geometries used are not subjected to the BIOS and IDE
limitations simultaneously: the logical geometry is subject
to IDE's 16 head limitation, but not to the 1024 cylinder
limitation. For the translated geometry, it is just the reverse.

Most BIOSes denote extended CHS translation with 'Large'. Note that
the geometry usually entered in the BIOS setup
is the logical geometry, not the translated one. In case of doubt,
consult the BIOS manual.

Logical Block Addressing (LBA) Here, the logical geometry is
dispensed with entirely and replaced by a single, large,
linear block number. This makes far more sense than using a logical
geometry that is completely fake anyway.

 +-------- DRIVE --------+    +- BIOS --+    +---- OS ----+
 |                       |    |         |    |   & APPS   |
 |   physical      T1    linear   T2  translated          |
 | geometry used  ====> block no.====> geometry           |
 |internally only        (LBA)           (CHS)            |
 |                       |    |         |    |            |
 +-----------------------+    +---------+    +------------+

This breaks the 504MB barrier in essentially the same way as
extended CHS does. Conceptually, using a single linear
number to address a sector on the harddisk is simpler than a CHS
style address, but it takes more CPU cycles and is
sometimes slower on the drive side as well. The differences are
pretty insignificant either way.

A translating BIOS can be implemented via the system BIOS or on-board
controller BIOS. Basically, this takes the drive's
logical default geometry, and if the cylinder count is beyond 1024, will
divide the cylinder count by an appropriate factor and
multiply the heads by the same. For instance, let's take a 540 Meg
drive: it has 1057 cylinders, 16 heads, and 63 sectors per
track. Well, the int13 interface used by the BIOS to talk with the world
can only handle 1024 cylinders, but it can address up
to 255 heads. So, the x-lating BIOS will pass to the OS, via int13
calls, the geometry 528 cylinders (1057/2 (approx)) and 32
heads (16*2). Then, when the OS makes a request to the drive, the BIOS
will re-translate the request to the original order, or
to an LBA number if LBA is enabled. This allows for capacities of up to
8 gigabytes.

A final word about the 8GB capacity limit, which is inherent in the
int13 interface and cannot be solved without ditching the
traditional calls. To that purpose, the IBM/Microsoft int13 extensions
document specifies a new interface between the BIOS
and the operating system or applications. These extended int13 calls are
made in terms of LBA addresses and can handle
huge disks. Note that the BIOS is required to translate these LBA
addresses back to CHS if the drive doesn't support
LBA---exactly the reverse of the translation process outlined above.

12.3 I'd like to know how translation works in detail.

You asked for it :-)

If a drive is less than 504MB, it should have a logical geometry, as
reported in Identify Device words 53-58, of 1024 or less
cylinders, 16 or less heads and 63 or less sectors. Such a drive can be
addressed directly without invoking this algorithm. For
drives over 504MB, the CHS address received by the BIOS from DOS must be
converted to an Extended CHS address, or
an LBA address. We'll assume ECHS for now.

First, during BIOS setup, the BIOS must determine the value of N. This
value is used to convert the drive's geometry to a
geometry that the BIOS can support at the int13 interface. This
interface requires that Cyl be less than or equal to 1024. The
number of cylinders (Identify Device word 1) is divided by N while the
number of heads (Identify Device word 3) is multiplied
by N. N must be 2, 4, 8,..., a power of 2.

Second, in most translating BIOSes, the following algorithm is used
whenever INT 13H is called to perform a read or write:

eCyl    = ( Cyl * N) + ( Head / dHead ); /* head DIV dHead */
eHead   = ( Head % dHead );              /* head MOD dHead */
eSector = Sector;                        /* used as is     */

By way of example, assume the drive's geometry is 2000 cylinders, 16
heads and 63 sectors (these numbers are in Identify
Words 1, 3, and 6) and that the BIOS determines the value of N to be 2.
The BIOS reports to DOS that the drive has 1000
cylinders, 32 heads and 63 sectors when int13 ah=08h function is called.
This is 2016000 sectors.

Note the following about this algorithm: The physical ordering of
sectors on the drive is unaffected---sector n is followed by
sector n+1 for all CHS and Extended CHS and LBA addresses. This is the
only sane way of implementing translation, but
unfortunately NOT ALL BIOSES DO IT THIS WAY. This means that changing
translation modes may be a dangerous
thing to do.

12.4 What is in the Enhanced Disk Parameter Table?

In a standard BIOS, the Fixed Disk Parameter Table (FDPT) contains
information about the geometry of the harddisk(s). It
more or less contains the same information as the drive type entry in
the CMOS setup. A program that wants to use the
harddisk on a low level, bypassing DOS, normally uses the BIOS' int13
functions to achieve this.

The Enhanced fixed Disk Parameter Table (EDPT) is an extension of the
ordinary FDPT that makes use of undefined fields to
provide information about the translation mode used. It uses a magic
number (A0 in byte 3) and a checksum (in byte 15) to
ensure that software cannot mistake random data for an EDPT. This
practice is more or less standard across various flavors of
translating BIOSes, with differing magic numbers.

On top of this, the Phoenix Enhanced BIOS standard specifies a number of
extended int13 functions and a 16 byte FDPT
extension. The latter contains detailed information about the current
PIO or DMA type, block mode used, LBA or (E)CHS
addressing, 32 bit transfer mode, media type (removable, CD-ROM),
control port base and IRQ. In other words, it covers all
new features of the ATA family and is flexible enough to accommodate
more than four devices, nonstandard port addresses
and IRQs. Proper support of all this is important to achieve any degree
of Plug'n'Play functionality with ATA hardware. The
WD EIDE BIOS lacks all these features.
See: http://www2.lmn.pub.ro/~byte/hardware/ata/atafq-12.html

Reinstall your network setup and network adapter. Record your
values before removing. Reboot

I have ever meet the same problem.
I think it is your network card is not very compatible
with the drive you use now.
My solution is to set the card mode to the 16 bit compatible
rather than the 32 bit.
I think this can help you to solve it and someday the newest drive discover , we will not need to set to the 16 bit.
My computer is IBM and with crystal on board pci lan card.

when you extract the two vxd's we spoke off, they should load properly.
if there was something else please comment.


Maybe it's time for someone to ask you, DO YOU NEED these files??
Are you having any errors in windows 95??? IF your answer is NO, and everything is O.K. so please refer to smeebud answer on the (3rd from top) it states clearly that some devices are not loading and it's O.K.

Now if your question was targetting WHY do they load at the first place allow me to sent you to WINDOWS95 GENERAL and go to the answered questions and the title of the question is "bootlog.txt failures" or here is the link:
Now don't forget to reward the person who spent the most time with you here, which in my opinion is smeebud.

magigraf, you said, "DO YOU NEED these files??".
That shows clarity of thought. How did I miss that.
You're saying "if it ain't broke don't fix it right"?
I agree, thanks:)

Exactly smeebud...
Sometimes little things are missed by the amount of informations we carry in our brain.
Indeed if everything if working fine WHY search for snakes??
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.