Ah, yes, srvany: the excuse to have not written a service in the first place. A kludge.
As far as I can tell, srvany was written to compensate for the fact that programmers don't
know how to write services, so would like to think they can run applications as services.
I find this a peculiar way to do business.
Have you actually logged the contents of the command line? That would be a good start. It
may well be that you are processing entirely different command lines under the two
scenarios, and therefore it is essential to know the exact contents of the command line in
both cases. If they are different, try to launch the interactive program with the exact
same command line as you find in the service launch, and study what happens. But in the
absence of any information about the contents of the command line, it is all guesswork.
On Mon, 23 Apr 2007 08:48:03 -0700, Marcos B. <MarcosB@discussions.microsoft.com> wrote:
Thanks for your response Joseph. Here are some clarifying details:
The application was developed as a regular MFC Windows application, but it
runs in production as a service using srvany.exe. The application just
displays one main window which shows the time when it connected to the
database.
Unfortunately I can't give you a lot of details about what the application
is doing before it crashes because I don't have Visual Studio installed in
the production server in order to run the application in the debugger. If I
do a remote debugging session from within VS in my laptop everything works
fine as I said in the original post. All I know (by writing some trace to a
text file) is that the last line executed before the crash is the call to
ProcessShellCommand.
Here is the portion of code that includes that call. I think most of this
code is generated by the Wizard:
//===================================================
BOOL CTT32CommServApp::InitInstance()
{
AfxEnableControlContainer();
// Standard initialization
// If you are not using these features and wish to reduce the size
// of your final executable, you should remove from the following
// the specific initialization routines you do not need.
#ifdef _AFXDLL
Enable3dControls(); // Call this when using MFC in a shared DLL
#else
Enable3dControlsStatic(); // Call this when linking to MFC statically
#endif
// Change the registry key under which our settings are stored.
// You should modify this string to be something appropriate
// such as the name of your company or organization.
SetRegistryKey(_T("Local AppWizard-Generated Applications"));
LoadStdProfileSettings(0); // Load standard INI file options (including MRU)
// Register the application's document templates. Document templates
// serve as the connection between documents, frame windows and views.
CSingleDocTemplate* pDocTemplate;
pDocTemplate = new CSingleDocTemplate(
IDR_MAINFRAME,
RUNTIME_CLASS(CTT32CommServDoc),
RUNTIME_CLASS(CMainFrame), // main SDI frame window
RUNTIME_CLASS(CTT32CommServView));
AddDocTemplate(pDocTemplate);
// Parse command line for standard shell commands, DDE, file open
CCommandLineInfo cmdInfo;
ParseCommandLine(cmdInfo);
// If we didn't get the username from the command line, exit.
if(username == NULL)
return FALSE;
// Dispatch commands specified on the command line
// if (cmdInfo.m_nShellCommand == CCommandLineInfo::FileNew)
// cmdInfo.m_nShellCommand = CCommandLineInfo::FileNothing;
if (!ProcessShellCommand(cmdInfo)) // Don't open the document yet.
return FALSE;
// Kick off the thread that will connect to the database, open the document
and monitor our connection to the database.
shutdownEvent = new CEvent(FALSE, TRUE, "Shutdown");
dbMonitorThread = AfxBeginThread(MonitorDatabaseConnection, (LPVOID) this,
THREAD_PRIORITY_BELOW_NORMAL);
// The one and only window has been initialized, so show and update it.
m_pMainWnd->ShowWindow(SW_SHOWMAXIMIZED);
m_pMainWnd->UpdateWindow();
return TRUE;
}
//===================================================
What makes it more mysterious is the fact that it works fine when I do
remote debugger and when I run it interactively through Terminal Service.
However if I run it interactively by looging on to the serer at the console,
it crashes. Again like I said, the application runs fine both interactively
and as a service on a development server.
I hope this helps. Please let me know if you want some more details or
something spoecific that might give you a better idea.
Thanks again.
Marcos B.
"Joseph M. Newcomer" wrote:
Either it is a service, and therefore cannot be double-clicked to launch it, or it is an
application, and therefore cannot be used as a service. If it is a service, you are
already in trouble because services cannot have GUIs, at least easily, and in any case
that capability has now been removed from Windows. The articles telling how to create a
service with a GUI have been removed from the MSDN.
A service with a GUI would have a WinMain, but a service is not launched with a command
line option, since the parameters are passed in via argc and argv to the ServiceMain
thread, not the main thread, so ProcessShellCommand would have erroneous assumptions about
what it is trying to do. Since you have simply given a vague handwave about it crashing
somewhere in MFC, without any details of exactly what it was doing, and you even used the
vague word "crash" as if this term has some meaning in diagnosing problems, it is
impossible to tell what is going on.
joe
On Thu, 19 Apr 2007 14:34:01 -0700, Marcos B. <MarcosB@discussions.microsoft.com> wrote:
The application is running in debug mode and it crashes on a Win2K production
server both when running interactively (by double-clicking on the exe when I,
an administrator on the box, am logged on to the server) and as a service
under a local account (which is part of the Admin group also). However, If I
run it under the LocalSystem account everything is fine.
Also, everything is fine if I run de application interactively through a
Terminal Server session or through Remote Debuging from the Visual Studio
environment running on my laptop.
The application works fine both interactivle and as a service under a local
account, on a Win2k development server as well as on my XP laptop.
In the cases where the application crashes, it always does it within MFC
function ProcessShellCommand.
The aplication was developed in Visual Studio 6.0, using the MFC AppWizard
(exe).
Has anybody had a similar experience? Why would ProcessShellCommand crash?
and why it works fine in many different scenarios as explained above? Any
ideas?
Thanks
Marcos B.
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]