Archived

This forum has been archived. Please start a new discussion on GitHub.

Error when stopping an Ice-based Windows service

I have a very simple Ice-based Windows service that starts just fine:

C:\ICT\bin>ICTViewerBridge.exe --start ICTViewerBridge
Service start pending.
Service is running.


However, when I try to stop it, I see in the console:

C:\ICT\bin>ICTViewerBridge.exe --stop ICTViewerBridge
Stop request sent to service.
Current state: 4
Exit code: 0
Service specific exit code: 0
Check point: 0
Wait hint: 0

and a message box pops up saying:

Debug Error!

Program C:\ICT\bin\ICTViewerBridge.exe

DAMAGE: after Normal block (#219) at 0x00397538


Things are slightly better if I compile in Release mode; I'm usually
able to stop the service with no errors. But occasionally I get a
msgbox saying:

The instruction at "0x0012e48c" referenced memory at "0x00000000".
The memory could not be "written".


Did I do something wrong? (See attached source...)


TIA,

Dave



#include <ViewerBridgeImpl.h>
#include <Ice/ice.h>
#include <Ice/Service.h>

using namespace ICT;

class ViewerService: public Ice::Service
{
private:
Ice::ObjectAdapterPtr adapter_;

protected:
virtual bool start( int argc, char* argv[] );
};

bool ViewerService::start( int argc, char* argv[] )
{
// Create an 'adapter' for the server
adapter_ = communicator()->createObjectAdapterWithEndpoints(
"ICTViewerBridgeAdapter", "default -p 48105" );

// Create/add a servant implementing the ICTViewerBridge interface
Ice::ObjectPtr obj = new ViewerBridgeImpl;
adapter_->add( obj, Ice::stringToIdentity( "ICTViewerBridge" ) );
adapter_->activate();

return true;
}



int main(int argc, char* argv[])
{
ViewerService svc;
return svc.main(argc, argv);
}

Comments

  • mes
    mes California
    Hi Dave,

    We will try to reproduce this, but it would help us to know the versions of Windows, Ice and Visual C++ you are using.

    Thanks,
    - Mark
  • > We will try to reproduce this, but it would help us to know the
    > versions of Windows, Ice and Visual C++ you are using.

    Of course--silly of me not to include this info in the first place. :-%
    I'm using Ice 2.1.1, Windows XP (SP2) and Visual C++ .NET Standard
    Edition (a.k.a. VC++ 7.1).

    I don't think it matters, but what I did was buy the 'cheap' version
    of the Visual C++ IDE that comes with compiler optimization disabled,
    and then replaced the compiler portion with the (optimizing) compiler
    from the (free) Visual C++ 2003 Toolkit, as described at:
    http://www.sawtoothdistortion.com/Articles/FreeOptimizingCompiler.html.
    I've been using this setup since October with no problems.

    Something that is more likely to be relevant is: I have my XP box
    tuned way, way down in terms of the number of services it runs at
    startup. I have turned off every service possible. 'COM+ System
    Application', for example, isn't running because I have no idea what it
    does and haven't needed it yet. Could it be that Ice::Service relies on
    some Windows service I have disabled?
  • From the error message, I would suspect memory corruption as the cause. Can you try using Purify?

    Cheers,

    Michi.
  • bernard
    bernard Jupiter, FL
    You don't need to have any Windows service running to use an Ice Service.

    For the debug error, do you use /MDd and the *d.lib Ice libs for everything?

    Cheers,
    Bernard
  • I don't have a licensed copy of Purify, but I tried installing an eval
    copy. I had no luck getting Purify to run my app as a Windows service,
    but the (text) output from running it *without* the '--service' arg is
    attached, FWIW. Is this helpful? (Purify did carp a lot about cases of
    'Freeing Mismatched Memory [FMMs]', and seemed to be pointing the finger
    at some Ice calls; but I've no prior experience with the utility, so I'm
    not sure what to make of any of this... :-% )
  • bernard
    bernard Jupiter, FL
    Could you relink your exe with /FIXED:NO to get rid of the FMMs?

    More details in:
    http://www.zeroc.com/vbulletin/showthread.php?t=1272

    Cheers,
    Bernard
  • Okay, I relinked with /FIXED:NO and now the Purify output looks
    clean[?]--as far as I can tell (see attached). To answer Bernhard's
    earlier question: yes, I'm using /MDd and linking with Iced.lib and
    IceUtild.lib.

    Can anyone offer advice about using Purify when the app is run as a
    service? What I tried is described below. Checking 'Allow service to
    interact with the desktop' did not have the effect the Purify online
    help seemed to imply it would, i.e., Purify did *not* start when I
    started the service. Trying to run the instrumented app from within
    Purify directly and specifying arguments of '--service ICTViewerTest'
    also didn't work. Any other suggestions? :-)


    C:\app\bin>purify /Run=no /Out=ICTViewerBridge_pure.exe test.exe

    Purify: While processing file C:\app\bin\ICTViewerBridge.exe:
    Note: Incremental linking has been allowed.
    Incrementally linked programs are not
    supported by Purify.
    Purify for Windows,
    (C) Copyright IBM Corporation. 1992, 2004. All Rights Reserved.
    Version 2003.06.03; Build: 5352;
    WinNT 5.1 2600 Service Pack 2 Uniprocessor Free
    Instrumenting:
    ICTViewerBridge.exe 913408 bytes

    Purify: Note: Compilation for "Edit and Continue" has been detected.
    Applying changes to a running program is not
    supported by Purify.

    Purify: Note: Instrumentation repeating with 7 additional entry points.


    C:\app\bin>test.exe --install ICTViewerBridgeTest

    [Ran services.msc, right-clicked ICTViewerBridgeTest and chose
    'Properties', and in 'Log On' tab checked 'Allow service to interact
    with desktop'.]

    C:\app\bin>test.exe --start ICTViewerBridgeTest
    Service start pending.
    Service is running.

    C:\app\bin>test.exe --stop ICTViewerBridgeTest

    [Got same error as before. Purify never started.]
  • mes
    mes California
    Dave,

    Just for the sake of completeness, can you post the rest of your sample service (specifically the ViewerBridgeImpl)?

    Thanks,
    - Mark
  • mes
    mes California
    Dave,

    You may already be aware of this issue, but you need to make sure that the service is configured to use the purified executable. For example, if purify is generating server_pure.exe, then the service needs to be configured for that executable.

    Note that using the command

    > server_pure --install MyServer

    does not register the service for server_pure.exe. We recommend using the following command to ensure that the correct executable is used for purify:

    > server --install MyServer --executable C:\Path\To\server_pure.exe

    Also, this page has information on using purify with a Windows service.

    Hope that helps,
    - Mark
  • Sure. Please see the attached example, which is lifted almost verbatim
    from section 8.3 of the Ice manual. This exhibits the same behavior
    on my machine when compiled using the attached project file. (Hopefully
    you'll find something blatantly wrong with the settings! :-> )
  • Mark--from your tip about how to change the service executable, I
    was able to get Purify to work with my TestService program. It appears
    to be crashing in ntdll.dll (see attached output file). It also flagged three
    Array Bounds Write errors (all in Ice::stringSeqToArgs()), but I'm guessing these
    are spurious(?)
  • mes
    mes California
    Hi Dave,

    Thanks for the purify log. We've encountered the same issues when trying to reproduce your situation. We've already got a fix for the ABW errors, but we're still trying to track down the access violation. Unfortunately purify isn't giving us much help on that one. We'll keep you posted.

    If you're willing to modify an Ice source file and rebuild the Ice library, you can fix the ABW problems by editing src\Ice\Initialize.cpp and commenting out the lines shown below in stringSeqtoArgs:
        if(argv)
        {
            argv[argc] = 0;
        }
    
    Note that this is just a temporary (but safe) fix. A better fix will be included in the next release.

    Thanks,
    - Mark
  • mes
    mes California
    Dave,

    We think we've located the problem causing the access violation. To fix it, you'll need to edit src\Ice\Service.cpp and add WINAPI as shown below:

    void WINAPI
    Ice_Service_ServiceMain(DWORD argc, LPTSTR* argv)
    ...
    void WINAPI
    Ice_Service_CtrlHandler(DWORD ctrl)

    Let us know if that helps.

    Thanks,
    - Mark
  • Just checked the behavior with Ice-2.1.2 (released today), and it does,
    indeed, fix the problem. Pretty impressive how quickly you guys were able to
    turn around a fix--thanks! I was going to build from source with the mods you
    suggested, but now I don't need to... :-)