Event ID 315 Error 2114 Revisted

It seems like the printer was maybe shared twice.  

Check the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Shares

If  it's listed twice, you may try to remove the share and registry values for the printer share and re-share it, with a different share name.

I've had massive problems with the LaserJet P2055 if it's connected via USB and I try to share it to other machines.  Print spooler crashes all over the place.

Use its network port and print to it directly rather than sharing it if at all possible.

Otherwise, on PCs with it connected and shared via USB I've often had to do horrible fudges on the clients who want to print to it - eg net use lpt2: \\server\printer   and then configure a "local" printer connected to LPT2!

Folks: Checked HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Shares and it's only listed once. Also it's connected via ethernet not USB. But I wonder. Perhaps when first I set it up two years ago, I did not set it up exclusively as a network printer. (I discovered a USB cable connected to the printer but not to the machine, as if I'd changed my mind.) Now I have to figure out how to check that setting and if need be correct it. I wonder how to reinstall it, or if that's necessary. Not sure where to look and what to look for.

It may show as a hidden device in device manager
http://support.microsoft.com/kb/315539

Open device manager using the process in the KB.
After it opens, go to VIEW - "Show hidden devices"

See if there are any grayed-out printers with the same name and uninstall by right clicking on it.

Followed the KB instructions, but there were no printers showing, none.

If you delete the share and re-share it with a different name, do you get the same error?

Is this what you're talking about?

Are there any errors in your event logs referring directly to the Server Service?

Cantoris: No errors referring to Server service, and I carefully checked all dependencies to make sure they were the defaults and/or were started.

tmassa: Sorry, didn't work. I changed the name of the shared printer and on reboot got a 315 Event error, and when the system came up, my audio service was disabled and had a red x through the speaker icon is the sys tray. Changed the name back to the original and the 315 event did not reappear on restart and the audio service was restored. But, please take a look again at a new snip of the ports in the properties tab:
You'll notice there are two ports listed for my printer: "HPLaserJetP2055dn" and "HPLaserJetP2055dn_copy_1." You'll notice that the "copy" is checked. Could this be contributing to the the 315 even though it deals with ports and not the server or spooler?

Also, I can temporarily get rid of the 315 by going into group policy>admin>printers and changing :allow print spooler to accept client connections, then to a cmd line/admin and issuing gpupdate. And this works whether I set that GP for setting for "allow" to "not configured" or "enabled." Whatever it's set at, as soon as I change to the other setting and gpupdate, 315 goes away until I either install a program or an update or get a power failure and have to "start windows normally" from the DOS screen. Any major changes, it seems, sets off a 315. I'm betting all I have to do is gpupdate, shut down and restart and it will work. But of course, this is ridiculous because it does not get at the underlying problem, which I'm hoping you experts can coax me toward.

Just a thought, try manually making new "ports" using the "Standard TCP/IP Port" instead of the HP one.  Assign these to the printer and then delete the old HP ports.

I've had very weird problems with the HP Standard TCP/IP Port.

You can try changing the policy back to "not configured" and reset the secedit.sdb file.

Just delete c:\windows\security\database\secedit.sdb and restart.

Tmassa: After your post, spent several days reading about secedit.sdb file. Understood some of what I read, which is that it holds both Group Policy and security settings. Wanted to know as much as I could before deleting it. You did not say so above, but I'm assuming when it is deleted Win creates a fresh one. And I think I read where it returns your security settings to default. That correct? Meanwhile, in my reading, I came across a tool to check the integrity of secedit.sdb. Here the cmd string: esentutl /g %windir%\security\database\secedit.sdb. Went to run the string and got this:

Not sure what to make of that. What data from the log files has yet to be placed in database and how does one get it there. In other words, how do I bring the database up to date, as the dialog suggests.

Have your deleted secedit from your machine at some point and what were the results? Again, since this is new to me, I'm trying to be cautious and not cripple a machine I use every day for work. Thank you for thinking about this.

I had an issue once where a desktop team cloned machines with a corrupt database, and GPOs wouldn't take, so we were able to delete it and and Windows would create a new one.  Never had an issue with it creating a new one on reboot.

You can try doing the repair if it makes you feel more comfortable.

Plan to effect GPO delete and recreate secedit this weekend.

tmassa: deleted secedit.sdb, restarted but the machine did not recreate it. Rebooted several times. Got a 315 with each and boot up took a long time. I'd made a backup copy of secedit.sdb and once it was restored, machine began to behave normally. Except every time I restarted, I got another 315. Then I experimented with the GP "Allow Print Spooler..." Changed back from "not configured" to "enabled, ran gpupdate in an admin cmd prompt, and 315 went away. This has happened before. When I change something on install something, the 315s start, and I go into GP, change back to non configured or enabled, depending on what it was set at, then gpudate at a cmd prompt, and the 315s go away.

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_scetroubletn.mspx?mfr=true

This was an XP-related article, but the ESENTUTL commands should be the same.  Instead of deleting, try the repair option:

Run esentutl /g to check the integrity of the security database at %windir%\Security\Database\Secedit.sdb.

If the database is corrupt:
1.  Attempt to recover it by running esentutl /r on the %windir%\Security folder. If this fails, attempt to repair it by running with esentutl /p on %windir%\Security\Database\Secedit.sdb.

2.  After that, delete the log files in %windir%\Security.

Will give it a try tomorrow.

1. Okay, before I proceed with recovery, I ran the /g option and got this:

C:\Windows\system32>esentutl /g %windir%\security\database\secedit.sdb

Extensible Storage Engine Utilities for Microsoft(R) Windows(R)
Version 6.1
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating INTEGRITY mode...
        Database: C:\Windows\security\database\secedit.sdb
  Temp. Database: TEMPINTEG3472.EDB

Checking database integrity.

The database is not up-to-date. This operation may find that
this database is corrupt because data from the log files has
yet to be placed in the database.

To ensure the database is up-to-date please use the 'Recovery' operation.

Operation terminated with error -550 (JET_errDatabaseDirtyShutdown, Database was
 not shutdown cleanly. Recovery must first be run to properly complete database
operations for the previous shutdown.) after 2.434 seconds.

2. Read a little bit about recovery mode and it said I needed the right logs and suggested running this (results included):

C:\Windows\system32>esentutl /mh %windir%\security\database\secedit.sdb

Extensible Storage Engine Utilities for Microsoft(R) Windows(R)
Version 6.1
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating FILE DUMP mode...
         Database: C:\Windows\security\database\secedit.sdb


DATABASE HEADER:
Checksum Information:
Expected Checksum: 0x0f6dacfd
  Actual Checksum: 0x0f6dacfd

Fields:
        File Type: Database
         Checksum: 0xf6dacfd
   Format ulMagic: 0x89abcdef
   Engine ulMagic: 0x89abcdef
 Format ulVersion: 0x620,17
 Engine ulVersion: 0x620,17
Created ulVersion: 0x620,17
     DB Signature: Create time:07/14/2009 00:48:54 Rand:270353 Computer:
         cbDbPage: 4096
           dbtime: 1366 (0x556)
            State: Dirty Shutdown
     Log Required: 1-1 (0x1-0x1)
    Log Committed: 0-1 (0x0-0x1)
  GenMax Creation: 10/09/2013 16:53:05
         Shadowed: Yes
       Last Objid: 20
     Scrub Dbtime: 0 (0x0)
       Scrub Date: 00/00/1900 00:00:00
     Repair Count: 0
      Repair Date: 00/00/1900 00:00:00
 Old Repair Count: 0
  Last Consistent: (0x1,9,112)  10/10/2013 16:35:23
      Last Attach: (0x1,A,183)  10/10/2013 16:35:23
      Last Detach: (0x0,0,0)  00/00/1900 00:00:00
             Dbid: 1
    Log Signature: Create time:10/09/2013 16:53:05 Rand:7330235 Computer:
       OS Version: (6.1.7601 SP 1 NLS 60101.60101)

Previous Full Backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00

Previous Incremental Backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00

Previous Copy Backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00
Previous Differential Backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00

Current Full Backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00

Current Shadow copy backup:
        Log Gen: 0-0 (0x0-0x0)
           Mark: (0x0,0,0)
           Mark: 00/00/1900 00:00:00

     cpgUpgrade55Format: 0
    cpgUpgradeFreePages: 0
cpgUpgradeSpaceMapPages: 0

       ECC Fix Success Count: none
   Old ECC Fix Success Count: none
         ECC Fix Error Count: none
     Old ECC Fix Error Count: none
    Bad Checksum Error Count: none
Old bad Checksum Error Count: none

  Last checksum finish Date: 00/00/1900 00:00:00
Current checksum start Date: 00/00/1900 00:00:00
      Current checksum page: 0

3. I have no idea what any of the above means. But I followed the recovery instructions and:

C:\Windows\system32>esentutl /r %windir%\Security

Extensible Storage Engine Utilities for Microsoft(R) Windows(R)
Version 6.1
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating RECOVERY mode...
    Logfile base name: C:\Windows\Security
            Log files: <current directory>
         System files: <current directory>

Operation terminated with error -1003 (JET_errInvalidParameter, Invalid API para
meter) after 0.0 seconds.

Here's what my security folder looks like:

Templates and logs are empty. No logs.

Here's what's in the database folder:


Can't access audit folder. Other folders don't look like they bear on the problem.

I might have had the wrong syntax on the recovery command: C:\Windows\system32>esentutl /r %windir%\Security.

Repaired Secedit.sdb. Still get an occasional 315. And now, in various programs, I get a period "ping" or "ding" sound. How the heck to I troubleshoot and stop that?

Tmassa: This didn't work but, in an oblique way, it may have led me to the answer. As I said, it's a network printer connected by ethernet cable. You suggested changing the name on the Sharing tab of properties, which disabled the sound service. But your suggestion made me look at the other choices in that tab. I had "Share this printer" checked, and it occurred to me that maybe WIN was trying to start the print spooler twice on startup, one for the network connection and another because by checking that box, I was telling the OS that the printer was connected directly to my PC. I unchecked the box. Just before I did that, to stop the 315 errors, I switched "allow print spoolers..." from enabled to "non-configured," and ran GP Update. (Previously I had gone through the drill with esentutl and Secedit.sdb, effecting a repair when a recovery of the security folder did not work. So it's possible that I simply temporarily stopped the 315s by yet again changing the GP. It's also possible your suggestion to change the name of the printer, which led me to uncheck sharing, is doing the job. If the 315s return, I'll start another ticket and we'll try again. Thanks.

Cool.  Glad you're making progress.  The repair should be run against the database file itself, and not the folder.

Esentutl /r %windir%\security\database\secedit.sdb

I see the instructions said folder, but I don't remember running against the folder in the past, but it's been awhile.