• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 649
  • Last Modified:

need help with instsrv

I am trying to create my own server.
I have no problems with creating the service and getting it to run, but i also need to be able to remove the service

when I try to remove the service by typing:

instsrv Myservice REMOVE

d:\nt\sdktools\reskit\content\instsrv\source\instsrv.c: Error 1783 from EnumServ
icesStatus on line 184

Does anyone know what this means?
Brad
0
Brad_nelson1
Asked:
Brad_nelson1
  • 6
  • 2
1 Solution
 
Brad_nelson1Author Commented:
By the way, i tried this on (2) windows 2003 servers and i get the same error.
0
 
cookreCommented:
1783 - The stub received bad data. - RPC_X_BAD_STUB_DATA
0
 
cookreCommented:
Two common ways to stop a service:

* The services.msc gui

* The SC command line:
   sc stop <svcname>

The SC command line has an advantage over services.msc in that it can also delete a service:
sc delete <svcname>
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
cookreCommented:
See if this helps any:
http://support.microsoft.com/default.aspx?scid=kb%3BEN-US%3B822751

It's for a different, but related, API
0
 
cookreCommented:
I dug up an old version of some source for instsrv and saw that it was, indeed, calling EnumServicesStatus() with a buffer size of well over 65k.
0
 
Brad_nelson1Author Commented:
Cookre what does that mean " buffer size well over 65k"  Im not a programmer so I could use some help.
0
 
FahdmurtazaCommented:
This means I think a buffer overflow command am I right  cookre .
Fahd Murtaza
0
 
cookreCommented:
It would appear as if some of the older API routines dealing with service enumeration in which you supply a buffer to receive ALL of the enumerated data (as opposed to other enumeration APIs that use a call back to provide enumerated items one at a time), have a wee problem when you specify a buffer size greater than 65K.  One presumes that's what the above linked-to patch fixes.

With respect to instsrv, I found an old source whose REMOVE option handler uses a deprecated call (Enu,ServicesStatus(), as opposed to the preferres EnumServicesStatusEx() in which the specified buffer size was about 140K.  

I have no idea how close this source matches the executable you're using.

Since you have the problem only on a REMOVE, I'd suggest using the SC commands:

SC STOP servicename
SC DELETE servicename

0
 
cookreCommented:
Oops, I ignored the question.

Is it a buffer overflow problem?  

Probably not in the sense we're used to hearing, to wit, an insufficiently sized buffer receives more data that it was intended to hold, so the excess just slops into the following memory, thereby causing various degrees of mahem.

In this case, well, here's the proximate cause:

The deprecated call:

BOOL EnumServicesStatus(
SC_HANDLE                       hSCManager,
DWORD                             dwServiceType,
DWORD                             dwServiceState,
LPENUM_SERVICE_STATUS lpServices,
DWORD                             cbBufSize,
LPDWORD                          pcbBytesNeeded,
LPDWORD                          lpServicesReturned,
LPDWORD                          lpResumeHandle
);

The buffer into which the status of registered services is plopped is pointed to by 'lpServices'.  The returned data is an array of _ENUM_SERVICE_STATUS:

typedef struct _ENUM_SERVICE_STATUS
{
LPTSTR lpServiceName;  
LPTSTR lpDisplayName;  
SERVICE_STATUS ServiceStatus;
} ENUM_SERVICE_STATUS, *LPENUM_SERVICE_STATUS;

SERVICE_STATUS is:
typedef struct _SERVICE_STATUS
{
DWORD dwServiceType;  
DWORD dwCurrentState;  
DWORD dwControlsAccepted;  
DWORD dwWin32ExitCode;  
DWORD dwServiceSpecificExitCode;  
DWORD dwCheckPoint;  
DWORD dwWaitHint;
} SERVICE_STATUS, *LPSERVICE_STATUS;

The documentation for EnumServicesStatus()
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/enumservicesstatus.asp
say that the maximum size for the buffer pointed to by lpServices is 64K bytes.  One specifies the size in 'cbBufSize'.

The preferred way to size the buffer is to call the routine first, specifying a cbBufSize of 0 to receive how large the buffer needs to be to handle the current batch of services.

What the old instsrv source I have does is simply declare:
#define                             SZ_ENUM_BUF   4096
ENUM_SERVICE_STATUS    essServiceStatus[SZ_ENUM_BUF];
DWORD   dwBufSize=sizeof(essServiceStatus);

and passes along that dwBufSize.

Now, since one instance of essServiceStatus is 44 bytes, it's passing a buffer size of 44*4096=180,224 bytes, well above the stated max of 65,535.  

My guess is that the API (interestingly enough still using 16-bit indexes (65K is the max for a 16-bit UINT)) builds its table in a max 65K area, then does a bulk copy based on cbBufSisze.  At some point during the copy, the index goes above 65K, and eventually leaves the area allocated, triggering an error that is, like many, mis-diagnosed.
0

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 6
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now