|
|
Home
Search
Register
Login
Recent Posts
»Forums Index
»Archive (2017 and earlier)
»IQFeed Developer Support
» Unhandled win32 exception in .NET 2.0 application
|
|
| Author | Topic: Unhandled win32 exception in .NET 2.0 application (4 messages, Page 1 of 1) |
 dis -Interested User- Posts: 24 Joined: Apr 16, 2007 |
Posted: Jun 22, 2007 08:12 AM
Msg. 1 of 4
Hello guys,
While testing my application on different use cases and situations, I have found a reproducible issue where a crush of my .NET 2.0 application occurs. It can be reproduced when I'm logging into IQFeed twice from different computers with the same account. On the first PC I see the following message: "IQConnect has been disconnected from the server. Please make sure you are logging in only once". At that time my application was performing the batch update of historical data for many symbols. It deals with IQFeed using COM interface (DTNHistoryLookup.dll). After the disconnect, my application crushed with unhandled win32 exception "access violation..." Here is my unmanaged stack trace (from last): ntdll.dll!7c918fea() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] ntdll.dll!7c919aeb() ntdll.dll!7c919ba0() ole32.dll!774ffaba() DTNHistoryLookup.dll!08e3ebb4() DTNHistoryLookup.dll!08e40214() ntdll.dll!7c90104b() DTNHistoryLookup.dll!08e3fa31() DTNHistoryLookup.dll!08e40214() DTNHistoryLookup.dll!08e3ea4c() DTNHistoryLookup.dll!08e3ea72() > mfc80.dll!ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > >::AllocSysString() Line 2185 + 0x40 bytes C++ DTNHistoryLookup.dll!08e3dd57() MSCTF.dll!74730e71() user32.dll!7e41f84a() user32.dll!7e41f7f6() user32.dll!7e41f805() user32.dll!7e41f805() user32.dll!7e41f94b() user32.dll!7e41f95b() ntdll.dll!7c90eae3() user32.dll!7e42e051() mfc80.dll!AfxInternalPumpMessage() Line 153 + 0xf bytes C++ mfc80.dll!CWinThread::Run() Line 625 + 0x7 bytes C++ mfc80.dll!_AfxThreadEntry(void * pParam=0x0c84f61c) Line 126 C++ msvcr80.dll!_callthreadstartex() Line 348 + 0x6 bytes C msvcr80.dll!_threadstartex(void * ptd=0x0b4aca30) Line 326 + 0x5 bytes C kernel32.dll!7c80b683() And here are the error details: Unhandled exception at 0x7c918fea in <myapp>.exe: 0xC0000005: Access violation writing location 0x61746174. EventLog item: Faulting application <myapp>.exe, version 1.0.0.0, stamp 467a9608, faulting module ntdll.dll, version 5.1.2600.2180, stamp 411096b4, debug? 0, fault address 0x00018fea. As you know, .NET Framework 2.0 provides exception wrapping. It means that they guarantee that all non .NET exception (as the native win32 exception) would be wrapped to .NET compatible exceptions and users will be able to catch and process them. However, framework bypasses this one. I think it's probably a bug in the framework. I do not assume that you, on your side, are doing something wrong. I'm just asking to check (once again) what's happening on the forced connection closure. It's very important for me as the same crush has been reproduced with other situation. Say, if my application is working for a few hours (requesting historical data and adding a watch list for about 700 symbols). Thus I cannot handle this exception and the crush doesn't give me the chance to save my data, workspace and so forth. I have to avoid it somehow. Thanks for your help and support. Have a nice day. Dis File Attached: vs2005 - Exception.jpg (downloaded 1732 times) |
|
DTN_Steve_S -DTN Guru- Posts: 2093 Joined: Nov 21, 2005 
|
Posted: Jun 22, 2007 10:57 AM
Msg. 2 of 4
The disconnect is going to happen becuase you are logging in from 2 separate computers on the same account.
Your IQFeed account only allows a single login. If you need to run 2 separate instances of IQFeed, you will need a second account. However, I am not certain why the DLL might be causing an application crash. In this situation, I would expect the DLL to finish the current request and return an error message for all requests thereafter. I will look into this further. |
|
dis -Interested User- Posts: 24 Joined: Apr 16, 2007 |
Posted: Jun 27, 2007 07:59 AM
Msg. 3 of 4
Some comments from MSDN forum:
Quote: I'd guess the COM server is starting up an unmanaged thread. The CLR is not going to trap unhandled SEH exceptions in unmanaged threads. They'll bomb your app, nothing you can do about it. The thread is here: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1784273&SiteID=1 It would be great if there wouldn't be any unhandled exceptions Sincerely, DIS |
|
DTN_Steve_S -DTN Guru- Posts: 2093 Joined: Nov 21, 2005
|
Posted: Jun 27, 2007 09:59 AM
Msg. 4 of 4
I did some brief testing with this using the COM example apps (both C++ and the VB examples) and I was unable to duplicate this.
These applications performed as I expected they would. The current request completes and any remaining requests return errors. The VB examples are written using the .NET 2.0 framework as well so I am wondering if it could be something specific to C#... Is it possible for you to email developer support with a copy of your app that I can test with or a small example app that duplicates the issue? |
|
|