DataGridView Tortuga 2

A quien pudiera ayudarme, gracias de antemano

Mi Contexo:
Windows Xp Profesional Versión 2002 - Sp2
Visual Basic Net 2005
Equipo:

Compaq Evo D510 CMT
Intel Pentium 4 CPU a 2.39 Ghz 504 Mb Ram

Mi problema es el llenado de un DataGridView,
que NO está conectado a ninguna Base de Datos,
por tanto aqui no hay DataAdapter ni DataRead

Se trata simplemente de Llenar el objeto, con datos "En Duro"

En primera instancia se agregan las filas necesarias al DataGridView

T = 351
With DataGridView.Rows
If .Count = 1 Then .Add(T)
End With

En segunda instancia, desde GWBasic, pasando por todos los QuickBasic, y
todos Visual Basic
desde el 1.0 hasta el 6.0 (excepto el 2.0, que nunca vi)... Se llena el objeto

For i = 1 To 351
im1 = i - 1
DataGridView(0, im1).Tag = "1" 'Celda Tipo CheckBox (Se
guarda ID)
DataGridView(0, im1).Value = 1 'Celda Tipo CheckBox (Se
guarda estado)
DataGridView(1, im1).Value = "A" 'Celda Tipo TextBox
DataGridView(2, im1).Value = 1 'Celda Tipo CheckBox
DataGridView(3, im1).Value = "B" 'Celda Tipo TextBox
DataGridView(4, im1).Value = 1 'Celda Tipo TextBox
DataGridView(5, im1).Value = "C" 'Celda Tipo TextBox
DataGridView(6, im1).Value = 1 'Celda Tipo TextBox
DataGridView(7, im1).Value = 1 'Celda Tipo TextBox
Next

Las propiedades de la Clase dónde se encuentra este código, no tienen ni
remotamente
algo que ver con Objetos COM

Al examinar el uso de la memoria, con el administrador de Tareas, desde que
el flujo entra
en For i, se "come" el 100% de la Ram y se produce lo siguiente

Se detectó ContextSwitchDeadlock

Message:
El CLR no ha podido realizar la transición del contexto COM 0x1a2008 al
contexto COM 0x1a2178
durante 60 segundos.
Es probable que el subproceso que contiene el contexto o apartamento de
destino esté en espera
sin proporcionar mensajes o que procese una operación de ejecución muy larga
que no proporcione
mensajes Windows.
Normalmente, esta situación tiene un impacto negativo en el rendimiento y
puede hacer que la
aplicación no responda o que acumule continuamente el uso de la memoria.
Para evitar este problema, todos los subprocesos de apartamentos de un único
subproceso (STA)
deberían utilizar primitivos de espera que proporcionen mensajes (como
CoWaitForMultipleHandles)
y proporcionar mensajes regularmente durante operaciones de ejecución largas.

Y también encontré esto:
El Ayudante para la depuración administrada (MDA) de ContextSwitchDeadlock
se activa cuando se
detecta un interbloqueo durante la transición del contexto COM.

Síntomas
El síntoma más común consiste en que una llamada realizada en un componente
COM no administrado
por parte de código administrado no vuelve.
Otro síntoma es una mayor utilización de la memoria de forma progresiva.

Motivo
La causa más probable es que un subproceso del apartamento de un único
subproceso (STA) no está
proporcionando mensajes.
El subproceso STA o está esperando sin proporcionar mensajes o está
realizando operaciones largas
y no está permitiendo que la cola de mensajes siga su curso normal.

La mayor utilización de la memoria se debe al subproceso del finalizador que
está intentando realizar una llamada a release en un componente COM no
administrado y a que dicho componente no está siendo devuelto. Esto evita que
el finalizador reclame otros objetos.

Resolución
Siga las reglas COM relacionadas con la distribución de mensajes STA.

Efecto en tiempo de ejecución
Este MDA no tiene ningún efecto en el CLR. Sólo comunica datos sobre
contextos COM.