HKCU entries getting damaged

[JordanCN]

Over the past few weeks 5 different users on 5 different computers have had a problem where the security on the HKEY_Current_User\Software\Pervasive key got messed up for the primary user of the computer, but no other user. We have been using these same computers with the same setups for years without a problem. No changes have been made except for several weeks ago (they and all the other computers) got the lastest Windows Updates. All of them had the issue days apart despite having updates weeks ago.

We are using an old DOS base MRP system on our Windows 2000 computers with the PSQL 2000i SP4 server and client. The affected user profiles open the DOS program and they get an error opening the first starting database file which is the security config file. The error is the Btrieve/Pervasive Bad File Mode error.

The only way to stop the error is to allow the Pervasive client to rebuild the HKCU\Software\Pervasive keys by deleting them and starting the program. The entries in these keys do not look different from what is on all the other computers however there is some sort of security issue problem because when I try to export the key from one profile to the other profile by creating .REG files I get errors saying the .REG file could not be imported because access was denied. This is even if I make the user and Administrator and take ownership of the registry keys.

Windows 2000 SP4 workstations
Windows 2000 SP4 Server
Pervasive P.SQL 2000i SP4 server and clients.

 

[mirtheil]

Have you changed anything recently that might account for these new problems? For example, have you changed anti-virus software? I've never seen anything like this. Another question, are your DOS applications using the BREQUEST/BREQNT or the BTRBOX interface?
What does REGEDT332 (to get permissions) show on a "good" machine and a "bad" machine in terms of the keys.
If you're able to make this happen, you might look into Regmon to see which process is changing the permission of the registry key.



Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician

http://www.mirtheil.com

 

[JordanCN]

I traced the issue down to the key by using Regmon. I have been checking they keys on a good machine vs a bad and I don't see a difference. Here is the HKCU keys for Pervasive. When I delete them they appear to just get recreated to the same as far as I can tell.

[HKEY_CURRENT_USER\Software\Pervasive Software\Communications Requester\Version 7\Settings]
"SatEntry0"="Proton,2,3,0"
"NumSatEntries"=dword:00000001
"SatEntry1"="Proton,0,4,3"

[HKEY_CURRENT_USER\Software\Pervasive Software\Microkernel Router\Version 7\Settings]
"Gateway Durability"="no"

I have also tried to use RegEdt32 to see what the security was on the keys. When I look at each key and setting one by one I don't see a problem. Admins, the user of the profile, and System all seem to have full control and the Restricted user appear to have Read access which looks OK to me.

There has been no AV changes other than the fact that the AV definition files get updated every day, but I would imagine that all the user would have been affected at once rather than spuratically over the past month and that it would happen to all users on the computer.

Windows Updates have all been deployed weeks ago so I don't know if that was the cause. That is the only thing that changes on these computers regularly in addition to the AV files.

Since the machines are Win2000 and XP I don't need to call BTRBOX or BreqNT because Pervasive put the following line in the Config.NT file:

DEVICE=C:\PVSW\BIN\BTRDRVR.SYS

 

[mirtheil]

That is interesting:
[HKEY_CURRENT_USER\Software\Pervasive Software\Communications Requester\Version 7\Settings]
"SatEntry0"="Proton,2,3,0"
"NumSatEntries"=dword:00000001
"SatEntry1"="Proton,0,4,3"

That's showing two different connection methods to the same server (Proton). The first is showing a LANMAN (WIndows) server using Namepipe address resolution and the second is showing and unknown server using DNS name resolution with a Lan adapter number of 3. This tells me that there might be more than just the registry problem. Is there anything in the PVSW.LOG on either the client or server around when these problems occur?

This information was pulled from the following Pervasive KB:
Solution Details
Solution ID: 00014450

What is the purpose of the SAT entries

Problem Description:

Problem Environment:
Pervasive.SQL v7
Pervasive.SQL 2000
Pervasive.SQL V8
SAT Entry

Cause of this problem:

Solution Notes:With Pervasive.SQL 7.0 and Pervasive.SQL 2000, a entry was added to the local BTI.INI or registry called SAT entries. They are used as a persistent cache that maintains information about the server, server type, and connection type.

The location of the SAT entries is
HKEY_LOCAL_MACHINE\Software\Pervasive Software\Communications Requester\Version 7\Settings

and beginning with Pervasive.SQL 2000 service pack 2
HKEY_CURRENT_USER\Software\Pervasive Software\Communications Requester\Version 7\Settings

For Pervasive.SQL V8 the location of the SAT entries is:
HKEY_LOCAL_MACHINE\Software\Pervasive Software\Communications Requester\Version 8\Settings


Each SAT entry has the following form:

SatEntry=ServerName with values of NOS, AddressResType, LANA

ServerName is the name of the file server

NOS is the Network Operating System with the following values:
0 = Unknown Server
1 = NetWare Server
2 = LANMAN server (including Windows NT)
3 = Local Drive


AddressResType is the Address Resolution Type with the following values:
0 = Unknown Address Resolution
1 = Bindery Address Resolution
2 = NDS Address Resolution
3 = Namepipe Address Resolution
4 = DNS Address Resolution
5 = Windows CE
6 = NetBIOS

LANA is the Lan adapter number which is a Virtual ID assigned by Windows to tell it whether NetBIOS is bound to SPX or TCP. With TCP or SPX, this value will not be present.

The SAT entries are not directly based on any other registry settings or external files, but are affected by which transport protocols and which networking client software is installed at the workstation. During Pervasive's Network Service Layer (NSL's) initialization, it attempts to figure out if TCP/IP, SPX, and/or NetBIOS is available to it and whether or not the Novell Client and/or the Microsoft networking clients are installed. The NSL may use any address resolution method that is appropriate based on available transports or network clients.

For the NOS portion of the SAT entry, the values are based on the following:
0 (Unknown) - NSL was unable to determine the target NOS; typically it is either a NetWare server, or the target server name was a dotted notation IP address in an ODBC DSN, or the target Pervasive.SQL engine is a Workgroup engine and not a server engine.
1 (NetWare) - typically set when NSL resolves the server name through either through the Bindery or through NDS (not DNS), and thus requires either that SPX be installed (that is NSL's 'trigger' to check the Bindery) or that the Novell client (calwin*.dll, clnwin*.dll) be installed; also see Note 1.
2 (LANMAN) - typically set when NSL is able to make a Named Pipe connection to the server, but see Note 1.

For the address resolution type of the SAT entry, the values are based on the following:
0 (Unknown) - should never happen, really just a placeholder.
1 (Bindery) - requires SPX, a NetWare client (either Novell's or Microsoft's) and that at least one NetWare server be present on the LAN. You should only see this value when the target server is a NetWare server or an NT server running Microsoft's File and Print Services for NetWare.
2 (NDS) - requires the Novell client (calwin*.dll, clnwin*.dll). You should only see this value when the target server is a NetWare 4.x or 5.x server.
3 (Named Pipe) - requires a Microsoft networking client and that the target server be an NT server engine. For Btrieve applications connecting to an NT server engine, this should always be the resolution method used. Note that you would not see this when the target is a Workgroup engine, even if the engine itself is running on a NT machine;
4 (DNS) - requires TCP/IP; typically you should only see this for NetWare servers, but you also can see it for P.SQL 2000 DSN's that specify an IP address as the server name.
5 (Windows CE)
6 (NetBIOS)

Note 1: Prior to P.SQL 2000 SP2, the Win32 NSL would get a list of all connected drive letters and determine which type of NOS (NetWare or Microsoft Windows) the drive was mapped to. (The NSL programmatically did a 'net use' command, and examined the value in the 'Network' field.) The very first time the NSL wrote out a SAT entry for one of the connected servers, it used this information in deciding which NOS value to put in the SAT entry. Due to an apparent defect in Novell's latest client however, this action had to be removed. Also realize that this is true only for the first time the particular SAT entry is created. For subsequent connections, NSL will use the NOS value in the SAT entry no matter what the 'net use' command tells it.

Note 2: Once NSL has created a SAT entry for a specific server name, it will continue to use the address resolution mechanism listed in the SAT entry as long as it can still get a valid server address with that mechanism, even if another mechanism might be more appropriate. For example, suppose you have a NetWare server named Server1, and NSL created a SAT entry for Server1 indicating that it used DNS (not NDS) to get the TCP/IP address. Next, and you down the NetWare server and brought up an NT server also named Server1. If NSL is still able to get the NT server's address via DNS, it will continue to do so instead of using the Named Pipe mechanism. If you wish to change the SAT entry, it is best to simply set the NumSatEntries value to 0 (zero), and let NSL recreate all of its entries.

Note 3: NSL only reads the SatEntryx values during initialization, and always writes them immediately prior to unloading. Thus, changing any SatEntry values will have no affect on any running NSL's, and will be overwritten when any running NSL is unloaded. If you wish to change any of NSL's registry values via regedit.exe, make sure that the NSL is not currently loaded by any running application.


Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician

http://www.mirtheil.com

 

[JordanCN]

I believe having the two entries might make sense since some of these computer are laptops with Wireless access as well. Sometimes they use the wireless connection when they are in different parts of the building.

Some may even use VPN so wouldn't they have 3?

 

[mirtheil]

No, there should only be one SATEntry per hostname. I just checked my laptop (which I use for wireless, lan, and VPN access) and only have one entry per hostname.

Is there anything in the PVSW.LOG on either the client or server around when these problems occur?

Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician

http://www.mirtheil.com