|
The Error property returns a license error
even though the HexGadget is still in within the evaluation
period.
|
 |
It is normal for the initial Error value to equal 2
("License file not found") if you haven't obtained a
license file yet. All functions should still work normally
during the evaluation period. If you're getting some other error
or you do have a license file, continue reading below.
|
|
|
|
|
The license file doesn't seem to be
working.
|
|
Check the Error property immediately after creating an
instance. If the value is 0, the license is working. Otherwise,
take note of the error and read below. |
|
|
| Error 2:
License file not found |
|
This is the most common license error, and it's easy to fix.
First, we need to point out that the license file mechanism
is extremely simple. When you create an object instance, the
component DLL will take its own filename, change the extension
to "lic", and look for a file of that name in the same
directory. That's all there is to it.
Thus, if you get this error even when you have a license file,
there are only four known causes:
- The license file is not in the directory with the DLL
- The license and DLL filenames do not match
- The user does not have Read permission on the license file
- You do not actually have a license file for the HexGadget
that is giving you the error
To find the problem, try the following:
- Make sure the license file is in the same directory as the
component DLL.
- Verify that the DLL you think you're using is actually the
one registered. Sometimes people make multiple copies of the
DLLs and lose track of which is currently registered. If in
doubt, you can use REGSVR32.EXE or reinstall the HexGadgets.
- Make sure you're looking at the error for the correct
HexGadget. You may be getting the error from a HexGadget
other than the one you licensed.
- Check permissions on the license file to ensure the
calling process can read it. If you're using ASP on IIS,
make sure the IUSR_[machine name] and IWAM_[machine name]
accounts have permission.
- See that the DLL and license filenames match (except for
the extension, of course). The 8.3 MS-DOS filenames also
need to match. You can check them by right-clicking on the
files in Windows Explorer, choosing Properties, and looking
at the MS-DOS name. For example, they might be
"HexVal~1.dll" and "HexVal~1.lic".
If you make any configuration changes, restart applications
using the component (such as IIS) to ensure the changes take
effect.
If you have tried these suggestions, and none of them worked,
don't give up. One of them is the answer. Other problems would
give you different errors (such as those listed below). You do
not have to reboot your machine or reinstall other software.
|
|
|
| Error 3:
Could not open license file |
|
The license file was found but could not be opened for
reading. Make sure the calling process has Read permission for
the license file. This error is very rare--you may have trouble
with your file system. |
|
|
| Error 4:
Corrupt license file |
|
The license file has been modified in some way. Sometimes
email systems or FTP will try to convert CRLF pairs in the file
to single LFs. In any case, restore your backup version or
obtain a new copy from Hexillion. |
|
|
| Error 5:
Wrong product license |
|
The component is not the product named in the license file.
Most likely the file has been renamed. License files can only be
used with the products for which they were created. |
|
|
| Error 6:
Wrong version license |
|
The component is a major version older or newer than that
specified by the license file. You'll need to obtain a license
file for the version you're using. |
|
|
| Error 7:
Unlicensed processors |
|
The component is executing on a machine with more processors
than the license file allows.
Perhaps you're trying to use a
1-processor license on a dual-processor machine, for instance. You'll need to switch to a machine
with fewer processors or upgrade your license for the difference
in cost.
If you're using a server with Xeon processors (or another
processor that supports hyperthreading), it could be that your
license covers your physical processors but not the number of
logical processors created by hyperthreading. With
hyperthreading, Windows and the HexGadgets will see double the
number of physical processors. If this is the case, simply contact
us and we give you a license file that covers the logical
processors.
|
|
|
"Server.CreateObject Failed"
"Can't create object" |
|
This isn't actually a license problem. HexGadgets will never
block object instantiation, even if they are unlicensed and the
evaluation period has expired.
Most likely causes for this error:
- The HexGadget is not properly registered. Try reinstalling
or use REGSVR32.EXE.
- The calling process does not have Read permission for the
component DLL. If you're using ASP on IIS, make sure the
IUSR_[machine name] and IWAM_[machine name] accounts have
permission.
- You're missing a required file. HexIcmp needs ICMP.DLL and
HexValidEmail needs HexDns. Apart from those, HexGadgets
only require standard system DLLs.
- Some other component or control is causing the error
instead of the HexGadget you suspect.
|
|
|
| License file is installed and working, but
the Expires property still returns a date.
|
|
This is normal. Expires always returns the built-in
expiration date, regardless of whether the HexGadget is
licensed. |
|
|
|
"Object doesn't support this property or method"
|
|
If you get this error on the Server.CreateObject line in your
VBScript code, you probably forgot the Set keyword. The syntax
should be:
Set obj = Server.CreateObject( ... )
|
"Could not obtain default server address"
"No DNS server
configured"
HexValidEmail error 536870927
|
|
HexDns (which HexValidEmail uses) was unable to obtain DNS
server addresses from your Windows TCP/IP properties.
If you're using HexDns directly, you have the option of
setting the Connection.RemoteAddr
property yourself. Otherwise, you will need to specify DNS
servers in your TCP/IP properties.
If you're on a corporate LAN, you may have to ask your
network administrator if a DNS server is available. (Also see
the question about proxies
and firewalls in the FAQ.) |
|
|
| Error
10049: Address not available |
|
This is an error passed up from Windows Sockets. In the
context of HexGadgets, it usually means you've tried to initiate
a network communication with the remote address set to 0.
- HexTcpQuery: You may have set the RemoteAddr
property to the return value of HexLookup.LookUp
without checking it. When the HexLookup.Lookup method
fails, it returns 0. Be sure to always check return values
and/or the Error
property after you call a method.
- HexDns: The Connection.RemoteAddr
property probably equals 0, which may mean HexDns was unable
to automatically obtain the DNS server addresses from your
Windows TCP/IP properties. You can either set Connection.RemoteAddr
yourself or enter addresses in your TCP/IP properties.
|
|
|
| All
method calls are failing |
|
The evaluation period has expired, and the HexGadget does not
have a working license file. If you've bought a license, check
the Error property to find out what's wrong. (Then see license
troubleshooting.) |
|
|
| Error
8002801d: Library not registered |
|
Usually you'll see an ASP script failing with this error after
logging in with your browser under a regular Windows user
account. If you log in as a Windows administrator, the script works fine.
This indicates the regular Windows user account doesn't have read
permissions for the HexGadget type library entries in the
registry. To correct the problem, you'll need to update the
permissions in the registry.
Follow the instructions in this Microsoft
KB article, but use the following TypeLib UUIDs:
HexDns
699278E2-0CA9-11D3-9D16-00A024FF8597
HexIcmp
E283C843-E11A-11D1-9C6F-76BF30000000
HexLookup
D1787864-E143-11D1-9C70-EC3406000000
HexTcpQuery
193DD963-ED2A-11D1-9C73-B03204000000
HexValidEmail
58FB8161-C554-11D3-9C17-00C04FA0D84C
|
|
|
|
Installation program
says the DLL self-registrations failed on Windows 95
|
|
The HexGadgets will not work on fresh installations of Windows
95 because some of the original system libraries are too old.
The easiest way to update the files is to install Internet
Explorer 4.0 or later. You can download IE from Microsoft
or the evolt browser
archive. |
|
|
|
HexValidEmail
instances fail with error 0x8000FFFF ("Unexpected" or
"Catastrophic") on Windows 95
|
|
You may need to update some of the Windows 95 system files as
described above.
Another possibility is that you may need to install HexDns.
HexValidEmail requires HexDns. |
|
|
|
HexGadget calls in
ASP seem to be "blocking" under heavy traffic
conditions.
|
|
It is normal for method calls to block briefly while waiting
for a network response. This should not affect scripts running
in other threads, however. If you're seeing performance problems
with heavy ASP traffic, the bottleneck very likely arises from
some aspect of your configuration:
- Don't place HexGadget instances in Session variables.
HexGadgets are apartment threaded, and you should create and
destroy them within the scope of a single page. Putting a
HexGadget object in a Session variable ties up one of the threads from your limited thread pool for
as long as the session remains active.
- Turn off server-side debugging for your ASP application
using Microsoft's management console. Server-side debugging
forces all ASP requests to run sequentially on a single
thread.
- Avoid using Session state for your application. All ASP requests
for a given session must execute sequentially.
- If you're using IIS4 or PWS4, consider increasing your
ProcessorThreadMax registry value. This increases the threads
available for processing ASP requests. (IIS5 adjusts the
thread pool dynamically and may not need any manual tuning.)
For more information on ProcessorThreadMax and other
performance optimizations, see these Microsoft articles:
|
