Net Hasp corrupting log-in scripts?????

[kccadcam]

Here's a really strange one...

We have one computer here (Dell p3 tnt2 Winnt4)

that when someone fires up Mastercam it kicks them out and corrupts their Netware log-in script.

We've went so far as to format C: and reinstall Winnt and still no luck.

Our IT guy is going nuts deleting log-in scripts and recreating them everytime some one trys to fire up Mastercam.

Anyone seen this before, or do we throw it out the window?!?!?

[kccadcam]

No takers on this one?

Could this be hardware related?(Mobo, Ram, etc.)

How many of you folks are running Net Hasp?

(Out of curiosity?)

[Guest CNC Apps Guy 1]

Not I said the fly...

[Bullines]

Where are the login scripts stored; on the server or client? It's been a while since I've been in a Novell forest

[kccadcam]

They are stored on the Server.

 

Mastercam is not finding the NetHasp server, but the NHASP9.exe program does.

 

[Bullines]

Does running NHASP9.EXE also corrupt the login scripts or do they only get corrupted when Mastercam is launched? Does running Mastercam with a local HASP on that computer cause the scripts to be corrupted as well?

[kccadcam]

quote:

---

Does running NHASP9.EXE also corrupt the login scripts or do they only get corrupted when Mastercam is launched?

---

I'm not sure I can tell. We only see the problem when Mastercam is started. NHASP9.exe always finds the server, but typically the 2nd time you run NHASP9, it doesn't seem to remember that it previously found the server. NHASP9 defaults back to 'Local' mode.

To be clear, the login scripts are not being corrupted, it's the person's roaming profile which gets corrupted in some unknown way.

 

 

quote:

---

Does running Mastercam with a local HASP on that computer cause the scripts to be corrupted as well?

---

The local HASP seems to work fine

[Bullines]

If it's just this computer that has problems and the exact same nethasp.ini file is being used on the exact same version of Mastercam, then that is indeed a weird problem. Is the computer on the same subnet as all of the other computers that are working fine? Does it matter which user logs into this computer? Does the computer have a crappy Realtec NIC or something similar?

[kccadcam]

All computers are on the same subnet. Once a user's profile is corrupted, that user can't use MasterCam on any computer which uses NetHasp. The NIC is an integrated 3Com PCI 3C905C-TX.

[Bullines]

Is the Novell server and NetHASP server the same computer?

[kccadcam]

No, actually my computer is the NetHasp server.

[I2B4U]

what Novell client are you running? are you running tcpip or ipx? have you tried a different novell client or better yet, without the novell client?

which version of Novell are running?

[Rick Damiani]

The hasp state is stored in user section of the registry. Specificly, it's stored in HKEY_CURRENT_USERSoftwareCNC Software, Inc. as the REG_SZ value Sim Type. Local would be 'H' while network would be 'N'.

 

If I had to guess, I'd say that the registry on the computer in question is corrupt, and it's corrupting the USER.DAT copied from the user's roaming profile location when the user attempts to make a change to the HASP settings. Another possibility is that the NHASP9.EXE program on that computer is damaged. Once the USER.DAT file becomes corrupt, things that depend on the settings in the unreadable section won't work. Like MasterCAM.

 

Try using REGEDIT to take a look at the HKEY_CURRENT_USERSoftwareCNC Software, Inc. key and see what happens to it when you use NHASP9.EXE to change the HASP type.

[kccadcam]

We have more information now.

 

The MasterCam Nethasp issue seems to have been related to each users rights to set some windows Registry settings.

 

Thanks Rick, for leading us in the right direction!

[Rick Damiani]

Glad it helped.

 

Rights in general can be difficult to troubleshoot. Rights in the registry are even more troublesome. Developers generally cannot determine what effect unfortunate combinaitons of rights might cause, so the error messages related to rights difficulties are almost always misleading.

 

Generally what I'll do in a CAD/CAM lab is assign the users the same registry rights as granted to the Power Users group. This does not make them Power Users, as there are several other user rights that they need to be able to take advantatage of that access. Generally it's only HKEY_LOCAL_MACHINESoftware that needs adjusting. Be careful not to inadvertently change the SYSTEM user's rights to any part of the registry. That can cause very strange and difficult to track down problems.

[kccadcam]

One thing that we observed with the registry is that the HKEY_LOCAL_MACHINESoftware registry entries appeared to be set correctly. It's the HKEY_CURRENT_USERSoftware registry entries that were not set, at least until we granted them registry edit rights.