In the OpGuide on page 61:
SERVER_PRIORITY_CLASS . Priority of the InterBase service on Windows server
platforms
. The value 1 is low priority, 2 is high priority
. Relevant only on Windows server platforms
. Default is 1
In the IBConfig file distributed with Interbase:
#SERVER_PRIORITY_CLASS 1
## Platforms: Windows
## Priority of the InterBase service on Windows
## The value 1 is low priority, 2 is high priority.
## Relevant only on Windows NT/2000/XP.
Just need a clarification when it is appropriate to change the
Server_Priority_Class from the default (1) to 2.
The comment in the IBConfig file makes it sound that the setting is only for
Windows NT/2000/XP, where the OpGuide says it is relevant only on Windows
server platforms. None of our servers use Windows NT/2000/WinXP (all are Window Server 2003, 2008, etc)
Thanks,
Tom Greenway
It does have an effect on any Windows version. The language in the comment stems from the days when IB was still supported on Windows 95.
However, you usually should not change this. Let the OS set thread priority.
Related
I have been trying to figure out why Wake On Lan works for Right Click Tools, but not for SCCM Scheduled Deployments.
In the wolmgr.log file I found this happening every five seconds: "Failed to get WOL inbox on AMT Proxy component. Wait 5 seconds... SMS_WAKEONLAN_MANAGER 9/19/2018 11:32:24 AM 480 (0x01E0)".
In the wolcmgr.log file I don't see any errors except this happening about four times a day, which I think is referring to the endless errors shown in the other log file: "CBaseCounter::Initialize - Registered performance counter "Total Number of Packets failed" SMS_WAKEONLAN_COMMUNICATION_MANAGER 9/19/2018 2:01:59 AM 9496 (0x2518)"
I have tried to look up these error messages and haven't found anything to help me get this resolved.
I have tried various ports, including the default (9) and 12287, currently it is on 7. We are being told to use subnet directed broadcasts by our network team due to some limitations with our Cisco network configuration.
I do have a SQL Server Agent (ADK) service that was disabled. I enabled it and it starts but turns off immediately. I don't know if that is related at all. I did have some deployment issues with Windows 7 drivers giving errors during the task sequence, even though they were installing. So I installed a Windows 8.1 ADK after seeing an article about bugs with the latest Win10 ADK and SCCM Task Sequences installing Win7 drivers. I've since then installed Win10 1703 ADK, which works on one of my other SCCM servers on Win7 deployments fine, and I was having this WOL problem before installing 1703 ADK.
Under Administration > System Status > Site Status > Management Point, when I show messages I see these:
*Description Severity
Type Site code
Date / Time System
Component Message ID
Thread ID Process ID
The Wake On LAN component has failed to read the site control file settings. Possible cause: The information is not yet available. Solution: The component is waiting for the information to become available and will retry obtaining the information at its next interval. Error
Milestone CML
9/20/2018 12:47:56 PM SMS_WAKEONLAN_MANAGER
6500 3384
3988
Description Severity
Type Site code
Date / Time System
Component Message ID
Thread ID Process ID
The Wake On LAN component has failed to read the site control file settings. Possible cause: The information is not yet available. Solution: The component is waiting for the information to become available and will retry obtaining the information at its next interval. Error
Milestone CML
9/20/2018 9:39:03 AM SMS_WAKEONLAN_MANAGER
6500 2924
2636*
ADK SQL Server Agent
SCCM WOL configuration
WOL ports
wolmgr.log file screen shot
RightClickTools WOL Configuration
I wonder because running it on a client's minidump it reports a different Windows version than the client repeatedly told me she had, and the version I'm being reported happens to be exactly the same version I'm running WinDbg on.
So I wonder, can vertarget always be trusted (and clients not) or the information it relies on may be absent with some dump generation options and when it is it reports the version WinDbg is currently running on, or maybe just some default that happens to coincide with my OS version?
I'm using WinDbg 6.12.
In all my cases so far, vertarget has been correct and the customer/client made a mistake - and vertarget is one of the commands I use for every dump, exactly for the purpose of checking if the dump contains what I need.
But perhaps, things can potentially go wrong here as well, so let's evaluate some options:
vertarget also reports debug session time and system uptime. Do those also match your system? Reboot your system in order to get a low system uptime and check again. Is it still your PC's uptime?
vertarget also reports the number of CPUs. Does that number match your number?
Get a virtual machine which does not have your OS, e.g. one from Modern.IE (Microsoft). Copy WinDbg and the dump to the VM and check the output of vertarget again.
WinDbg 6.12 is a bit old. Do newer versions (6.2.9200 / 6.3.9600 or even 10.0) provide the same information or was there a bug fixed already?
And even check some other information:
Is it a dump of the correct application? Use | (pipe)
Is it a dump of the version you are expecting? Use lm vm <exename>
Does it have the flags which can be expected for the method used for taking the dump? Use .dumpdebug.
Other than that I observe (not representative) that many client OS version dumps (Windows 7, 8, 8.1) have all latest service packs installed, while administrators seem to follow the "never change a running system" approach for server OS (Windows Server 2012, R2). So it might just be a coincident.
I have a fc14 32 bit system with 2.6.35.13 custom compiled kernel.
When I try to start G-wan I get a "Segmentation fault".I've made no changes, just downloaded and unpacked the files from g-wan site.
In the log file I have:
"[Wed Dec 26 16:39:04 2012 GMT] Available network interfaces (16)"
which is not true, on the machine i have around 1k interfaces mostly ppp interfaces.
I think the crash has something to do with detecting interfaces/ip addresses because in the log after the above line I have 16 lines with ip's belonging to the fc14 machine and after that about 1k lines with "0.0.0.0" or "random" ip addresses.
I ran gwan 3.3.7 64-bit on a fc16 with about the same number of interfaces and had no problem,well it still reported a wrong number of interfaces (16) but it did not crashed and in the log file i got only 16 lines with the ip addresses belonging to the fc16 machine.
Any ideas?
Thanks
I have around 1k interfaces mostly ppp interfaces
Only the first 16 will be listed as this information becomes irrelevant with more interfaces (the intent was to let users find why a listen attempt failed).
This is probably the long 1K list, many things have changed internally after the allocator was redesigned from scratch. Thank you for reporting the bug.
I also confirm the comment which says that the maintenance script crashes. Thanks for that.
Note that bandwidth shaping will be modified to avoid the newer Linux syscalls so the GLIBC 2.7 requirement will be waved.
...with a custom compiled kernel
As a general rule, check again on a standard system like Debian 6.x before asking a question: there is room enough for trouble with a known system - there's no need to add custom system components.
Thank you all for the tons(!) of emails received these two last days about the new release!
I had a similar "Segmentation fault" error; mine happens any time I go to 9+GB of RAM. Exact same machine at 8GB works fine, and 10GB doesn't even report an error, it just returns to the prompt.
Interesting behavior... Have you tried adjusting the amount of RAM to see what happens?
(running G-WAN 4.1.25 on Debian 6.x)
I have a Windows Service application (developed in C++) running under Local System account. Operating system is Windows Server 2008 Standard - Service Pack 2 - 32-bit - 4Gb RAM.
Also running Office 2003 with Service Pack 3.
This service takes a RTF file and using DDE prints it with Microsoft Word. However Word fails to perform the print issuing an error (I can see the error if I enable interaction with desktop). The error is
"Run-time error '1001':
There is insufficient memory. Save the document now.
C:...\file.rtf"
A screenshot can be seen here: http://img804.imageshack.us/img804/9550/worderror.png
It used to work on Windows 2003.
Any idea? Suggestions? Could be permission related?
This is actually not supported by Microsoft: http://support.microsoft.com/kb/257757
We had an application that uses Process.GetProcessesByName() but it is failing only on one user PC with the following error:
Process performance counter is disabled
I searched the registry for the Disable Performance Counters entry but it was not present with the value set to 1.
The user env is XP with administrative rights.
I know that on Windows Server 2003, the user account needs to be a member of the Performance Counter Users Group in order to accomplish this.
Any ideas on how to enable Process performance counter?
Issues that can be responsible: .NET version isn't compatible , Performance Counters need to be enabled or permission problems
Quoted from MSDN
In .NET 1.0/1.1, the Process class relys on performance counters to provide performance information regarding local and remote processes.
.NET 2.0, this dependancy for local processes is no longer present.
This exception can be thrown for a couple of reasons:
Performance counters are disabled - The Windows Resource Kit contains a tool called the Extensible Counter List that can be used to enable/disable counters
The user doesn't have enough rights - non-admin users (I think) may not have enough permissions to access the performance counters.
If it's possible, install .NET > 2.0 and target the newer version
There is a tutorial which shows you how to use the Extensible Counter List to enable Performance Counters here
Open Performance Monitor by clicking Start > Run > Type in Perfmon and choose Ok.
Verify that the Process Monitor object exists, as illustrated in the screenshot posted above.
If the Process object exists, choose all of the Process objects counters and all instances, click Add, and then watch the graph.
Do they all run successfully?
If the counters are missing, then you will need to enable them.
Microsoft provides several KB articles to handle this situation. Begin by reading http://support.microsoft.com/default.aspx?kbid=300956
If the steps in this KB not work properly, and if your server is Microsoft Windows Server 2003, try the next step
Download and install the Windows Server 2003 Resource Kit on the Notification Server or Task Server
Open the Windows Server 2003 Resource Kit command prompt
Type in "exctrlst.exe" to bring up the Extensible Counter List as shown in the screenshot below and scroll down and enable performance counters