ByRef error though parameter is passed by ByVal

I'm getting an error while trying to fill a grid (third party). The code is as follows:

Public Sub FillTheGrid(ByRef one As String, ByRef two As String, ByRef three As String)
Dim s As String
Dim e As Short = 0
s = (one & Chr(9) & two & Chr(9) & three).ToString
e = grdUAH.AddItem(s, 0) < Error for this
grdUAH.Row = 0
grdUAH.Col = 1
grdUAH.CtlRefresh()
End Sub

Though there is no value passed a ByRef, I get the error as: Byref value type parameter cannot be null.
If I comment out the line e = grdUAH.AddItem(s, 0), there is no error!

The stack is as below:

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.Runtime.Remoting.RemotingException: Byref value type parameter cannot be null.
at System.Runtime.Remoting.Proxies.RealProxy.ValidateReturnArg(Object arg, Type paramType)
at System.Runtime.Remoting.Proxies.RealProxy.PropagateOutParameters(IMessage msg, Object[] outArgs, Object returnValue)
at System.RuntimeType.ForwardCallToInvokeMember(String memberName, BindingFlags flags, Object target, Int32[] aWrapperTypes, MessageData& msgData)
at MSGrid.IGridCtrl.AddItem(String Item, Object Index)
at AxMSGrid.AxGrid.AddItem(String item, Object index)
at MFRAMEH.frmMain.FillTheGrid(String& one, String& two, String& three) in C:\ToVB.NET\MFRAMEH-socketNOTtcp\frmMain.vb:line 593
at MFRAMEH.frmMain.Timer1_Tick(Object eventSender, EventArgs eventArgs) in C:\ToVB.NET\MFRAMEH-socketNOTtcp\frmMain.vb:line 464
at System.EventHandler.Invoke(Object sender, EventArgs e)
at System.Windows.Forms.Timer.OnTick(EventArgs e)
at System.Windows.Forms.Timer.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr idEvent, IntPtr dwTime)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.573
CodeBase:file:///c:/windows/microsoft.net/framework/v1.1.4322/mscorlib.dll
-
MFRAMEH
Assembly Version: 1.0.2410.16790
Win32 Version: 1.0.2410.16790
CodeBase:file:///C:/ToVB.NET/MFRAMEH-socketNOTtcp/bin/MFRAMEH.exe
-
DatabaseComponents
Assembly Version: 1.0.2398.29092
Win32 Version: 1.0.2398.29092
CodeBase:file:///C:/ToVB.NET/MFRAMEH-socketNOTtcp/bin/DatabaseComponents.DLL
-
Microsoft.VisualBasic.Compatibility
Assembly Version: 7.0.5000.0
Win32 Version: 7.10.3077
CodeBase:file:///c:/windows/assembly/gac/microsoft.visualbasic.compatibility/7.0.5000.0__b03f5f7f11d50a3a/microsoft.visualbasic.compatibility.dll
-
System.Data
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.573
CodeBase:file:///c:/windows/assembly/gac/system.data/1.0.5000.0__b77a5c561934e089/system.data.dll
-
System
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.573
CodeBase:file:///c:/windows/assembly/gac/system/1.0.5000.0__b77a5c561934e089/system.dll
-
System.Xml
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.573
CodeBase:file:///c:/windows/assembly/gac/system.xml/1.0.5000.0__b77a5c561934e089/system.xml.dll
-
Microsoft.VisualBasic
Assembly Version: 7.0.5000.0
Win32 Version: 7.10.3052.4
CodeBase:file:///c:/windows/assembly/gac/microsoft.visualbasic/7.0.5000.0__b03f5f7f11d50a3a/microsoft.visualbasic.dll
-
System.Windows.Forms
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.573
CodeBase:file:///c:/windows/assembly/gac/system.windows.forms/1.0.5000.0__b77a5c561934e089/system.windows.forms.dll
-
System.Drawing
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.573
CodeBase:file:///c:/windows/assembly/gac/system.drawing/1.0.5000.0__b03f5f7f11d50a3a/system.drawing.dll
-
System.Data.OracleClient
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.573
CodeBase:file:///c:/windows/assembly/gac/system.data.oracleclient/1.0.5000.0__b77a5c561934e089/system.data.oracleclient.dll
-
System.EnterpriseServices
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.573
CodeBase:file:///c:/windows/assembly/gac/system.enterpriseservices/1.0.5000.0__b03f5f7f11d50a3a/system.enterpriseservices.dll
-
AxInterop.Threed
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase:file:///C:/ToVB.NET/MFRAMEH-socketNOTtcp/bin/AxInterop.Threed.DLL
-
AxInterop.MSGrid
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase:file:///C:/ToVB.NET/MFRAMEH-socketNOTtcp/bin/AxInterop.MSGrid.DLL
-
AxSSPanelArray
Assembly Version: 1.0.2382.23438
Win32 Version: 1.0.2382.23438
CodeBase:file:///C:/ToVB.NET/MFRAMEH-socketNOTtcp/bin/AxSSPanelArray.DLL
-
Interop.Threed
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase:file:///C:/ToVB.NET/MFRAMEH-socketNOTtcp/bin/Interop.Threed.DLL
-
Accessibility
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.573
CodeBase:file:///c:/windows/assembly/gac/accessibility/1.0.5000.0__b03f5f7f11d50a3a/accessibility.dll
-
Interop.MSGrid
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase:file:///C:/ToVB.NET/MFRAMEH-socketNOTtcp/bin/Interop.MSGrid.DLL
-
Interop.StdType
Assembly Version: 2.0.0.0
Win32 Version: 2.0.0.0
CodeBase:file:///C:/ToVB.NET/MFRAMEH-socketNOTtcp/bin/Interop.StdType.DLL
-

************** JIT Debugging **************
To enable just in time (JIT) debugging, the config file for this
application or machine (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the machine
rather than being handled by this dialog.

How do I solve this?

[8162 byte] By [Krutika] at [2008-2-11]
# 1

Hi-

What happens if you change the method signature to:

Public Sub FillTheGrid(ByVal one As String, ByVal two As String, ByVal three As String)

'...

I'm not sure why you're seeing this exact error. Also, I see Remoting in the callstack. Are you using remoting? In what mode?

thanks,

Paul

PaulYuk_MS at 2007-8-31 > top of Msdn Tech,Visual Basic,Visual Basic Interop and Upgrade...
# 2

I did try changing all parameter to ByVal, still the error persists.

I even change the contents as e = grdUAH.AddItem("hi", 0), still the error stays.

I'm not using remoting as per my knowledge.

I'm connecting a mainframe thru a socket and retreiving data. Will this require remoting?

Krutika at 2007-8-31 > top of Msdn Tech,Visual Basic,Visual Basic Interop and Upgrade...
# 3

I'm going to ask a colleague who works more with sockets to see if special conditions apply. We'll get back to you soon.

thx

Paul

PaulYuk_MS at 2007-8-31 > top of Msdn Tech,Visual Basic,Visual Basic Interop and Upgrade...
# 4
Thank you. Just for your info, this is part of a migration project from VB6 to VB.NET (.NET framework 1.1). And I'm using System.Net.Sockets.Socket instead of Winsock.
Krutika at 2007-8-31 > top of Msdn Tech,Visual Basic,Visual Basic Interop and Upgrade...
# 5

This actually looks like a problem with the 3rd party control and not with your code. The only thig that comes to mind is to verify that all the dlls used by the 3rd party control are present and registered correctly in your system.

Hope this helps,

MSFTAbelValadez at 2007-8-31 > top of Msdn Tech,Visual Basic,Visual Basic Interop and Upgrade...
# 6
In this case, I have used the same third party grid utility in another process and is working fine after migration. But for this process, its throwing errors
Krutika at 2007-8-31 > top of Msdn Tech,Visual Basic,Visual Basic Interop and Upgrade...
# 7

Is it possible to have a repro so that I can debug it on my machine? Looking at the stack trace is not very helpful. I am intrigued why in the list of loaded assemblies ‘System.Runtime.Remoting.dll’ is not present.

-Gagan

<gagangup at hotmail dot com>

GaganGupta at 2007-8-31 > top of Msdn Tech,Visual Basic,Visual Basic Interop and Upgrade...
# 8

Grid is part of many intertwined processes. I may not be able to send you a repro.

I'm not using Remoting.dll at all. I have not even added that in my project references.

Krutika at 2007-8-31 > top of Msdn Tech,Visual Basic,Visual Basic Interop and Upgrade...
# 9

Sometimes Remoting is used internally. I did some search but didn't find anything interesting. Without a repro it will be very difficult. I will try to find out another way of getting more information. Did you try creating a simple VB application that just uses the third party grid and does what you do in the FillTheGrid()?

Can you send a dump file or give me remote access to the machine?

-Gagan

GaganGupta at 2007-8-31 > top of Msdn Tech,Visual Basic,Visual Basic Interop and Upgrade...
# 10

The grid works fine in VB6 but after migration for one particluar process, its behaving odd.

I'm sorry I cant give remote access, but how to get a dump file?

Krutika at 2007-8-31 > top of Msdn Tech,Visual Basic,Visual Basic Interop and Upgrade...
# 11

Here are few links that give information on how to create a dump. I would recommend you to first try to find out a way to create a dump using the debugger you are using. It will be the least time consuming.

http://cc.msnscache.com/cache.aspx?q=3885690935062&lang=en-US&mkt=en-US&FORM=CVRE3

http://support.microsoft.com/?kbid=241215

http://www.microsoft.com/downloads/details.aspx?FamilyID=e089ca41-6a87-40c8-bf69-28ac08570b7e&DisplayLang=en

GaganGupta at 2007-8-31 > top of Msdn Tech,Visual Basic,Visual Basic Interop and Upgrade...
# 12

You mentioned that the third party grid worked in another process. What are the differences between the way you used it in that process and now?

It is possible that there is a bug with the way third party grid is written. We can't say for sure without debugging through the code. You may want to talk to the third party that wrote the grid. They may already know of an issue or can help you debug. If needed they can get in touch with us and we can work together to find the solution.

Thanks,

-Gagan

GaganGupta at 2007-8-31 > top of Msdn Tech,Visual Basic,Visual Basic Interop and Upgrade...
# 13
This looks like a problem with the Runtime Callable Wrapper that .NET automatically generates to marshal to an out-of-process ActiveX component. It would help a lot of we'd know the signature of the AddItem() function. I can see from the stack trace that it takes a BSTR and a VARIANT for the arguments but I can't see the return value type. Your code suggests that it returns a VB6 integer. But does it really?

You can use the OleView.exe utility to look at the type library for the ActiveX component. You'll find it in the Common7\Tools\Bin folder. Click File + View TypeLib and open the component. Post any line you'll see that mentions AddItem.

Other things to try is to declare 'e' as Object or to omit it alltogether...

nobugz at 2007-8-31 > top of Msdn Tech,Visual Basic,Visual Basic Interop and Upgrade...
# 14

Is it possible that it just needs a variable instead of a value in the second parameter?

dim index as integer = 0

e = grdUAH.AddItem(s, index)

Just a thought ...

DeborahK at 2007-8-31 > top of Msdn Tech,Visual Basic,Visual Basic Interop and Upgrade...