Switching server/mission problem

Hi!

I have two dedicated servers running on different ports and using different missions. I have a trigger in each mission file used to switch between the two servers.

My missiontrigger looks like this:

function missionTrigger::onEnterTrigger( %data, %obj, %colObj )
{
  %client = %colObj.client;
  
  if (%client) {
    switch$(%obj.nameTag) {
    case "egyptTrigger":
      CommandToClient(%client, 'nextMission', "192.168.0.69", "28003", false );
    case "testTrigger":
      CommandToClient(%client, 'nextMission', "192.168.0.69", "28000", false );
    }
  }
}

The client command schedules the actual change of mission:

function clientCmdNextMission( %strIp, %iPort, %bLocal ) {
  schedule(100,0,"changeMission", %strIp, %iPort, %bLocal );
}

The change of mission looks like this:

function changeMission( %strIp, %iPort, %bLocal) {
  
  //Disconnect from running mission
  disconnect();

 if(!%bLocal) {
    new GameConnection(ServerConnection);
    ServerConnection.connect( %strIp @ ":" @ %iPort );
  }
  else {
    ...
  }
}

The disconnect function is more or less the same as the one defined in fps/server/scripts/serverConnection.cs in the Demo - that is:

function disconnect()
{
   // Delete the connection if it's still there.
   if (isObject(ServerConnection))
      ServerConnection.delete();
   disconnectedCleanup();

   // Call destroyServer in case we're hosting
   destroyServer();
}

function disconnectedCleanup()
{
   // Terminate all playing sounds
   alxStopAll();
   if (isObject(MusicPlayer))
      MusicPlayer.stop();

   //
   LagIcon.setVisible(false);
   PlayerListGui.clear();
   
   // Back to the launch screen
   Canvas.setContent(MainMenuGui);

   // Dump anything we're not using
   clearTextureHolds();
   purgeResources();
}

AND NOW TO THE PROBLEM:

Sometimes when doing the switch the client crashes. The crash always happens just as the player is dropping from the sky :D
In the begining I thought it was the communication between client and server that coursed the problems. A little debuggging showed this was not the case. The crash happens in a TextureHandle??

Unhandled exception at 0x006df4a4 in torqueDemo_DEBUG.exe: 
0xC0000005: Access violation reading location 0x3f80000c.

inline U32 TextureHandle::getGLName() const
{
   if (!object)
      return 0;

  --> U32 useName = object->texGLName;
   if (TextureManager::areSmallTexturesActive() && object->smallTexGLName != 0)
      useName = object->smallTexGLName;

   return useName;
}

What could be coursing such a behavior? Could it be textures from the previous mission that have not yet been correctly removed on the client?
Or is it rather the removal that is coursing the problem?

Any surgestions are most wellcome. Thanks in advance ...