指定的位置找不到硬件信息

各位大侠，我现在做好了一个驱动，编译连接全都通过，并且我写了一个INF文件，可是当我启动控制面板进行安装准备调试的时候，Windows98却总是提示说在＂指定的位置找不到硬件信息＂，不知道为什么，请高手指点一二！！

你的inf文件的pid,vid号对不对啊，

应该吧问题说得详细点啊
什么设备
inf文件怎么写的
关键的那几个section都列来看看:-)

这在msdn或ddk里面有的：再列一份
Device Drivers Technical Articles  

Microsoft Windows 2000 Network INF FormatVersion 1.05

Microsoft Corporation

November 1998

Contents
File Names for INFs
Base Form for INFs
Net Component Information
Network and Print Providers
Network Adapters (including virtual and software-enumerated adapters)
WAN Devices
Windows 95 Values and Keys Not Used in Windows 2000

Please refer to the Microsoft? Windows? 2000 DDK "INF Files" for the Windows 2000-specific enhancements to the general information file (INF) format (www.microsoft.com/ddk/).

File Names for INFs
File names must still observe the 8.3 filename size limit for any INF shipped with the Windows 2000 operating system because of technical issues with the product install. Third-party INFs are not limited specifically by this rule.

The convention for INF file names is to start the name with a token representing the general class installer that will be used. With networking INFs, this token is Net. Following this, a token representing the manufacture or adapter model is usually used for adapters, or a token based on the Component ID is used for network software pieces.

Base Form for INFs
All component INFs will follow the standard INF format and contain several essential pieces of information needed for the Class Installers to correctly identify components in an INF and install them. The standard format is documented in the Windows 2000 DDK. These pieces include the Version, Manufacturer, Device, Main Install, and Strings sections in the INF.

Key points are:

Four different net classes currently exist: Net (adapters), NetTrans (protocols), NetClient (providers), NetService (all others).
The Class entry under the Version section is the previous way of defining the class for this INF. However, ClassGUID should be used in the future.
Net GUID is {4D36E972-E325-11CE-BFC1-08002BE10318}
NetClient GUID is {4D36E973-E325-11CE-BFC1-08002BE10318}
NetService GUID is {4D36E974-E325-11CE-BFC1-08002BE10318}
NetTrans GUID is {4D36E975-E325-11CE-BFC1-08002BE10318}
The Provider entry under the Version section defines who developed the INF, not who developed the component it is installing.
The Manufacturer section lists the developer(s) of the components and the Device section that lists the components for that manufacturer.
The following illustrates an example:

[Version]
Signature    = "$Windows NT$"
Class        = Net
ClassGUID    = {4D36E972-E325-11CE-BFC1-08002BE10318}
Provider     = %Msft%

[Manufacturer]
%ManufacturerName% = DevicesSection

[DevicesSection]
; DisplayName Section DeviceID
; ----------- ------- --------
%Adapter1.DeviceDesc% = a1.ndi, PCI\VEN_0000&DEV_0000

If a network INF is created that can be processed on both Windows 2000 and Windows 95/98, the signature should be $CHICAGO$, and a compatible line should be added.

The following illustrates an example:

[Version]
Signature    = "$Chicago$"
Compatible   = 1
Class        = Net
ClassGUID    = {4D36E972-E325-11CE-BFC1-08002BE10318}
Provider     = %Msft%

Components List and the Main Install Section
Within the Device section is a list of components that the INF supports for the manufacturer. The entries follow the format defined in the Windows 2000 DDK. The Component ID is also known as the device or hardware ID for actual devices. The Install section lists operations to perform, including registry changes, file copying, and so on. The Characteristics value allows the component to define what it supports, including whether it has UI to display properties, whether it can be removed, and whether the item is user viewable.

Key points are:

For all INFs other than adapter INFs, these Component IDs are unique and, as such, should include a Provider signature followed by an underscore and then a Manufacturer/Product signature. An example would be MS_DLC or MS_IBMDLC.
The Description is user-viewable text and thus must be %token% and represented in the Strings section.
The Characteristics value is used to describe a component and restrict the user's actions on a component. The following table lists possible values.
Note   The NCF_USER_REMOVABLE characteristic in Beta 1 has now become NCF_NOT_USER_REMOVABLE. This means Beta 1 INFs with the characteristic should remove it; those that did not have it now need to add it.
NCF_VIRTUAL (0x1) The component is a virtual network adapter.
NCF_SOFTWARE_ENUMERATED (0x2) The component is a software-enumerated component. (See the Windows 2000 DDK for information on software-enumerated components)
NCF_PHYSICAL (0x4) The component is a physical network adapter
NCF_HIDDEN (0x8) The component should not be shown in any user UI. (See the ControlFlags section in this document for more information about hidden components.)
NCF_NO_SERVICE (0x10) The component does not have an associated service.
NCF_NOT_USER_REMOVABLE (0x20) The component cannot be removed by the user (for example, through the Control Panel, Device Manager, Hardware Wizard, etc.).
NCF_MULTIPORT_INSTANCED_ADAPTER (0x40) The adapter has multiple ports that are installed as separate devices. That is, the adapter has multiple ports that have separate device IDs and can be installed individually.
NCF_HAS_UI (0x80) The component supports UI to change its properties.
NCF_DONTEXPOSELOWER (0x1000) The component does not expose components below it in binding paths.

Notes:

NCF_VIRTUAL, NCF_SOFTWARE_ENUMERATED, and NCF_PHYSICAL are mutually exclusive.
NCF_NO_SERVICE cannot be used with NCF_VIRTUAL, NCF_SOFTWARE_ENUMERATED, or NCF_PHYSICAL.
The following illustrates an example:

[DevicesSection]
; DisplayName           Section ComponentID
; -----------           ------- --------
%Adapter1.DeviceDesc% = a1.ndi, PCI\VEN_0000&DEV_0000

[a1.ndi.NT]
AddReg          = a1.reg
Characteristics = 0x4 ; NCF_PHYSICAL

Strings section
The Strings section contains all text seen by the user and is thus localizable text. See the Windows 2000 DDK for more information (www.microsoft.com/ddk/).

The following illustrates an example:

[Strings]
Msft                 = "Microsoft"
ManufacturerName     = "The Manufacturer"
Adapter1.DeviceDesc  = "Adapter1 10 BaseT"

ControlFlags section - ExcludeFromSelect
The ExcludeFromSelect directive in the ControlFlags section is mandatory for Plug and Play-enumerated adapters and for components that should not be added by the user (that is, those that should only be added programmatically). ISA (but not Plug and Play ISA), EISA, and MCA adapters are all physical root enumerated devices that can be added manually by the user and thus should not be listed in this section.

The presence of a component's ID in ExcludeFromSelect indicates that the component should not be shown in the Select Device dialog. Note that this differs from the NCF_HIDDEN characteristic; a component can be excluded from the Select Device dialog and still be visible to the user in the Connections UI (for example, ATM Emulated LAN). See the Windows 2000 DDK for more information. The following illustrates an example:

[ControlFlags]
ExcludeFromSelect = PCI\VEN_0000&DEV_0000

Net Component Information
The Main Install section will refer to AddReg sections that add values to the registry to define the component for network configuration. This includes all needed information to finish the install, bind the component to other network components, and allow the component to define a private NotifyObject.

NotifyObject and Network Component Support
In the registry sections referenced by the Main Install section, the root key (also known as HKR) is the component's instance key in the registry. As in Windows 95 INFs, a registry section referenced by the Main install must create the Ndi key. Specific information must be supplied under the Ndi key if the component has a NotifyObject.

The value ClsID should contain the GUID for the component object. The ComponentDll value should contain the path to the DLL that contains the NotifyObject. The Service value should contain the name of the primary service for the component. The value must match the first parameter of the AddService INF key that installs the service.

The CoServices value is a list of service names that the component installs. This is required to be present for all non-netclass components. Any service-related actions performed on the component will affect all the services in the CoServices list as ordered and only if present. An optional ExcludeSetupStartServices value can be specified if the starting of some services will have problems during the product install. The HelpText value is used by the UI to help the user understand how the component is used; this value should be a localized string.

Key points are:

Net class components do not support notify objects. If a physical or virtual Net class component needs to be involved in the install or remove process, use the device Co-Installer mechanism described in the Windows 2000 DDK.
If the ClsID and ComponentDll are not supplied, no NotifyObject is supported by the component.
If the ClsID and ComponentDll are supplied, the Main Install section must copy this file, and the class installer will call the DLL to register the COM object after the Main Install section has completed. The ComponentDll entry must contain the full path to the DLL if it is not in the System32 directory.
Supply the name of the primary service in the Service value. This must match the first parameter of the AddService INF key. This value is not necessary (and should not be specified) if the component has NCF_NO_SERVICE as one of its characteristics.
Supply the name of all services that are installed which are not represented by another component in the CoServices value; include your primary service. This value is a MultiSz. The services will be started in the order given when the component is installed and stopped in reverse order when the component is removed.
Note   Physical, software-enumerated, and virtual adapters should not list a CoServices entry.
If any service listed in the CoServices should not be started during the installation of the product, list it in the MultiSz value ExcludeSetupStartServices.
Supply the HelpText value, which is a friendly description of the functionality provided by the component.
The following illustrates an example:

[MS_Protocol.ndi.reg]
HKR, Ndi, ClsID,                     0,       "<ClsID>"
HKR, Ndi, ComponentDll,              0,       "<Component DLL>"
HKR, Ndi, HelpText,                  0,       %MyTransport_Help%
HKR, Ndi, Service,                   0,       "MYT3"
HKR, Ndi, CoServices,                0x10000, "MYT3", "MYT3CO"
HKR, Ndi, ExcludeSetupStartServices, 0x10000, "MYT3CO"

[Strings]
MyTransport_Help = "This protocol enables your machine to ..."

Interface Definition and Bindings
The Interface key should be added together with several values to define how this component binds to other components.

Key points are:

The UpperRange value defines the interfaces this component can bind to at its top edge.
The LowerRange defines the interfaces this component can bind to at its lower edge. For physical devices, this should be the media type supported.
The DefUpper and DefLower values described in the Windows 95 Networking INF documentation are not used in Windows 2000.
The following illustrates an example:

[Client1.ndi.reg]
HKR, Ndi\Interfaces, UpperRange, 0, "UInterface1, UInterface2"
HKR, Ndi\Interfaces, LowerRange, 0, "LInterface1"

The following is a current list of valid interface names:

Name Description
ethernet Lower edge for an ethernet network adapter
atm Lower edge for an ATM network adapter
tokenring Lower edge for a token ring network adapter
serial Lower edge for a serial network adapter
fddi Lower edge for an FDDI network adapter
baseband Lower edge for a baseband network adapter
broadband Lower edge for a broadband network adapter
arcnet Lower edge for an Arcnet network adapter
isdn Lower edge for an ISDN adapter
localtalk Lower edge for a Local Talk adapter
wan Lower edge for a generic Wan wrapper (RAS)
nolower Lower edge for any component that has no lower interface
adsl Lower edge for ADSL adapters
ndis5 NDIS 5.X (ndis2, ndis3, and ndis4 should no longer be used)
ndisatm NDIS 5 with ATM specifics
netbios NetBIOS
ipx IPX
tdi TDI
winnet5 Upper edge for a Windows 2000 network provider (NetClient)
noupper Upper edge for any component, meaning no upper interface
ndiswan upper edge for WAN adapters (includes ISDN adapters)

In Windows 2000, there is also a set of interfaces for protocol specific bindings. This is covered in Binding to a Specific Protocol.

Install and Remove
This information has changed since Beta 1. Ndi\Install sections are no longer supported, and the way the Remove section is found has been changed.

In Beta 1, components could list an additional install section through the Ndi\Install registry key. Post-Beta 1, these extra sections should be merged with the main section. The following illustrates an example:

Beta 1 INF
[ComponentsSection]
; DisplayName Section ComponentID
; ----------- ------- --------
%Protocol1.DeviceDesc% = p1.ndi, MS_PROT

[p1.ndi.NT]
AddReg = p1.reg
Characteristics = 0x20 ; NCF_NOT_USER_REMOVEABLE

[p1.reg]
:
HKR, Ndi\Install, , 0, "MyInstall"
:

[MyInstall]
AddReg    = yas.reg
CopyFiles = yas.CopyFiles

[MyInstall.Services]
AddService = p1, 0, p1.ServiceInstall, p1.EventLog

Post-Beta 1 INF
[ComponentsSection]
; DisplayName            Section ComponentID
; -----------            ------- --------
%Protocol1.DeviceDesc% = p1.ndi, PCI\VEN_0000&DEV_0000

[p1.ndi.NT]
AddReg          = p1.reg, yas.reg
CopyFiles       = yas.CopyFiles
Characteristics = 0x20 ; NCF_USER_REMOVEABLE

[p1.reg]
:
:

[p1.ndi.NT.Services]
AddService = p1, 0, p1.ServiceInstall, p1.EventLog

In Beta 1, the remove section name was arbitrary and specified through the Ndi\Remove registry key. Post-Beta 1, the remove section should no longer be specified via the registry. Instead, the remove section needs to be specified as <main section>.Remove. See the following examples:

Beta 1 INF
[ComponentsSection]
; DisplayName            Section ComponentID
; -----------            ------- --------
%Protocol1.DeviceDesc% = p1.ndi, MS_PROT

[p1.ndi.NT]
AddReg = p1.reg
:
Characteristics = 0x20 ; NCF_USER_REMOVEABLE

[p1.reg]
:
HKR, Ndi\Remove, , 0, "MyRemove"
:

[MyRemove]
DelReg = yas.reg

[MyRemove.Services]
DelService = p1

Post-Beta 1 INF
[ComponentsSection]
; DisplayName           Section ComponentID
; -----------           ------- --------
%Protocol.DeviceDesc% = p1.ndi, MS_PROT

[p1.ndi.NT]
AddReg = p1.reg
:
Characteristics = 0x0

[p1.reg]
:
:

[p1.ndi.NT.Remove]
DelReg = yas.reg

[p1.ndi.NT.Remove.Services]
DelService = p1

Note   Remove sections are not supported for Net class components. Because Net class components support multiple instances, there isn't a viable way to utilize Remove sections. If any work needs to be done on remove, use a device co-installer. See the Windows 2000 DDK for more information (www.microsoft.com/ddk/default.htm). Remember that multiple instances of your device can be present, so removing shortcuts, helper files, etc. is not recommended unless your co-installer implements a reference counting scheme.
RequiredAll
By specifying RequiredAll in a component's Ndi registry key, a component can install another net component. See the following example:

[ndi.reg]
HKR, Ndi, RequiredAll, 0, "<component id>" ; <component id> is the inf id of the component to install

RequiredAll should only be used if a component requires another component that cannot be installed by the user (for example, hidden components). Components listed in the RequiredAll key should not bring up UI during installation.

Note   A component that requires another component must ensure that the required component's INF is present in the INF directory. This is done in the first component's CopyFiles section.
Windows 2000 Services
Service sections can be supplied for a component (mandatory for net class devices). When the install section is found and processed, the component installer will search for a section by the same name with ".Services" appended. If the installer finds this section in the INF, it will install the services as listed. See the Windows 2000 DDK "Driver Installation