Troubleshooting guide

If you can't find an answer here, try the Technical FAQ.





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:

  1. The license file is not in the directory with the DLL
  2. The license and DLL filenames do not match
  3. The user does not have Read permission on the license file
  4. 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:






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:


All queries return an empty string, but the Error property equals 0. 
This usually indicates some sort of interference on the network, most likely a firewall or proxy server between you and the server you're querying. See this FAQ entry for information on using HexTcpQuery under these circumstances.
Show site map

contact us    privacy policy    legal information