[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1302
  • Last Modified:

Strong name for unsafe C++ assembly (dll) to be calles by C# application

Hello, I am trying to import (Dll import) into a C# application, a C++ dll, wrapping a third party USB driver API. Everything runs smoothly but sometimes the application consumes even up to 99% of cpu. By running process check up, I have discovered that from time to time (at moments of high cpu load) an invisible exception occurs, at the dll level related to the StrongNameErrorInfo. Next to that exceptions related to unregisterassembly and other similar issues.
Well started searching for Strong, Weak name signing assembly and found nothins related to this situation.
Does anyone have a solution?

Thanks.  
0
ivanadu
Asked:
ivanadu
  • 4
  • 2
1 Solution
 
abelCommented:
might it be that the "next to that exceptions..." are a result of the earlier exceptions? I.e., that the unwinding in the dll does not go smoothly and hence the unregisterassembly etc do not work as smoothly either?

it seems likely that the error either occurs in your wrapper, or in the third party usb driver. Maybe you can add structured exc. handling in your wrapper (if not already there) to at least log any exceptions that occur from the driver?
0
 
ivanaduAuthor Commented:
I'll give it a try. I am back within an hour :)
0
 
ivanaduAuthor Commented:
ntdll.dll!KiFastSystemCallRet
FTD2XX.dll!FT_IoCtl+0x56
mscorwks.dll+0x1b4c
mscorwks.dll!DllUnregisterServerInternal+0x61ad
mscorwks.dll!StrongNameErrorInfo+0x53ee
mscorwks.dll!StrongNameErrorInfo+0x55a6
mscorwks.dll!StrongNameErrorInfo+0x56ca
MyDll.dll!MyThreadFunction+0x83
KERNEL32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

ptr is a reference to a function from the c# application passed at init time.
Most of the times this works, and when the communication load is high it fails.

typedef void (__stdcall *pTempMessageHandler)(unsigned long);
 
	unsigned long bytes2Read;
	unsigned long bytes2Send;
	unsigned long eventStatus;
 
	pTempMessageHandler ptr = (pTempMessageHandler)pContext;
	while (applicationRun == true)
	{
		unsigned int uiTemp = WaitForSingleObject(hEvent,INFINITE);
		try
		{
		if (applicationRun == true)
		{	//(handle, *dword, *dword,	*dword);
			FT_STATUS ft_status = FT_GetStatus(ftHandle,&bytes2Read,&bytes2Send,&eventStatus); 
			(ptr)(eventStatus);
		}
		}
		catch (char * str)
		{
			//cout << "Exception raised: " << str << '\n';
		}

Open in new window

0
Never miss a deadline with monday.com

The revolutionary project management tool is here!   Plan visually with a single glance and make sure your projects get done.

 
ivanaduAuthor Commented:
Solved, thread not in dll but in c#, manualreset instead of autoresetevent in c++ dll, no loops in dll, c# thread calls blocking receive function from dll. upon receiving manually reset event in c++. none of the events are exchanges between c# and c++ dll. ...

thanks anyway
0
 
abelCommented:
glad you found it. I was just thinking of a way to help you further, but it isn't easy with this type of errors if you're not behind the machine (physically or remotely).
0
 
ivanaduAuthor Commented:
i know, once you search for such an error, you wonder if that is the right path. simplifying was the only option and minimizing interaction between c# and c++...
still not sure about this manually reset event, but once in correct position before reading how many bytes are in the queue i do not expect problems  

thanks again
0

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now