What is ntdll!_SEH_epilog ? Is the first occurence of it the place where the real issue is?

What is ntdll!_SEH_epilog ? Is the first occurence of it the place where the real issue is? - native

Does calling the ntdll!_SEH_epilog function, synonym of emmiting a system SEH exception ?
I have dozens of dump files which display the same stacktrace. It's in a mixed C++/C# environment.
CLR's legacyCorruptedStateExceptionsPolicy enabled="true" has been set for the product. And we also have our own SEH Handler, which is namely responsible for the dump file generation.
However, analyzing the dump file, I wonder if I'm not analyzing the problem too late, too late in the stack.
Because, if I look at the very very beginning of the really long managed/native stack, there's a ntdll!_SEH_epilog, before the problem that I have been focused on for now. (What I have analyzed for now is pointed by the dump file as a NullReferenceException. But at this point it is indeed really hard to have a null object, unless new has return null...)
In a nutshell windbg !dumpstack look like this, and I suspect the line 0905fd18 7c91aa5a ntdll!_LdrpInitialize+0x246 , calling ntdll!_SEH_epilog at the bottom to be indeed the original problem.
0:023> !dumpstack
0905a008 7c8094e5 kernel32!CreateFileMappingW+0x10b , calling ntdll!NtCreateSection
0905a7ec 59a8ba78 dbghelp!MiniDumpWriteDump+0xc8 , calling dbghelp!MiniDumpProvideDump
...
OurNativeSEHManagement::CreateDumpFile+0x155 <== write the dump file
...
0905ef6c 7920cb4e clr!CLRVectoredExceptionHandlerPhase2+0xff , calling clr!_EH_epilog3
...
0905efa4 0040e9de OurNativeSEHManangement::ProcessException <== this is our own SEH management
0905efdc 004127a5 OurNativeSEHManangement::HandleException <== this is our own SEH management
0905eff8 7c9444a8 ntdll!RtlCallVectoredExceptionHandlers+0x48
0905f018 7c933f56 ntdll!RtlDispatchException+0x19 , calling ntdll!RtlCallVectoredExceptionHandlers
...
0905f084 7915c620 clr!SigPointer::SizeOf+0x17c , calling clr!_EH_epilog3
0905f090 7c90e48a ntdll!KiUserExceptionDispatcher+0xe , calling ntdll!RtlDispatchException
*** a null reference exception is emitted in the line below ***
0905f398 088d4da3 (MethodDesc 0871df48 +0x13 One.Of.Our.Business.Class.ProxyStateHandler(System.Object, System.EventArgs)) ====> Exception Code c0000005 cxr#905f0c4 exr#905f0a8 <== this one is due to a NullReferenceException
...
0905f34c 7c910323 ntdll!RtlpImageNtHeader+0x56 , calling ntdll!_SEH_epilog
0905fc40 7c91abe7 ntdll!LdrpInitializeThread+0x13b , calling ntdll!_SEH_epilog
...
0905fca8 7c91aa5a ntdll!_LdrpInitialize+0x246 , calling ntdll!_SEH_epilog
*** is the following line the original problem indeed ? ***
0905fd18 7c91aa5a ntdll!_LdrpInitialize+0x246 , calling ntdll!_SEH_epilog
0905fd1c 7c90d06a ntdll!ZwContinue+0xc
0905fd20 7c90e45f ntdll!KiUserApcDispatcher+0xf , calling ntdll!ZwContinue
0905ffa0 791f59f6 clr!Thread::intermediateThreadProc+0x39 , calling clr!_alloca_probe_16
0905ffb4 7c80b729 kernel32!BaseThreadStart+0x37
Below, I include a more complete, yet still extremely simplified stacktrace ( I removed lots of lines, but it keeps the spirit of the original 900 lines stacktrace)... Overall it looks like a fireworks of SEH for my eyes, if ever calling ntdll!_SEH_epilog is really synonym of emitting a system SEH exception.
Should I consider the first occurrence of ntdll!_SEH_epilog as the real problem, or first consequence of the real problem ?
0:023> !dumpstack
OS Thread Id: 0x5d0 (23)
Current frame: ntdll!KiFastSystemCallRet
ChildEBP RetAddr Caller,Callee
0905a004 7c90d18a ntdll!NtCreateSection+0xc
0905a008 7c8094e5 kernel32!CreateFileMappingW+0x10b , calling ntdll!NtCreateSection
0905a020 7c80b9d7 kernel32!CreateFileMappingW+0x14a , calling kernel32!SetLastError
...
0905a1fc 59a8c4a0 dbghelp!GenAllocateModuleObject+0x2ce , calling dbghelp!_SEH_epilog
...
0905a288 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
...
0905a454 7c9101db ntdll!RtlAllocateHeap+0xeac , calling ntdll!_SEH_epilog
...
0905a620 59a8ac32 dbghelp!WriteFullMemory+0x1e1
0905a694 59a8b7d8 dbghelp!WriteDumpData+0xfd , calling dbghelp!WriteFullMemory
0905a6b0 59a8b97b dbghelp!MiniDumpProvideDump+0x171 , calling dbghelp!WriteDumpData
0905a7ec 59a8ba78 dbghelp!MiniDumpWriteDump+0xc8 , calling dbghelp!MiniDumpProvideDump
...
OurNativeSEHManagement::CreateDumpFile+0x155 <== write the dump file
... at least one hundred of ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog ...
0905c5f0 7c910041 ntdll!RtlFreeHeap+0x1e9 , calling ntdll!RtlpFreeToHeapLookaside
0905c5f8 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
0905c610 7c91080b ntdll!RtlFreeHeap+0x2e9 , calling ntdll!RtlpCoalesceFreeBlocks
0905c618 7c910940 ntdll!RtlFreeHeap+0x4fc , calling ntdll!RtlLeaveCriticalSection
0905c620 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
0905c630 7c9100b8 ntdll!RtlpFreeToHeapLookaside+0x22 , calling ntdll!RtlpInterlockedPushEntrySList
0905c63c 7c910041 ntdll!RtlFreeHeap+0x1e9 , calling ntdll!RtlpFreeToHeapLookaside
0905c644 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
0905c660 79175deb clr!RtlFreeHeap+0x2f , calling ntdll!RtlFreeHeap
0905c674 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
...
0905c6f8 7c910222 ntdll!RtlpAllocateFromHeapLookaside+0x42 , calling ntdll!_SEH_epilog
0905c724 7c910222 ntdll!RtlpAllocateFromHeapLookaside+0x42 , calling ntdll!_SEH_epilog
0905c728 7c91019b ntdll!RtlAllocateHeap+0x1c2 , calling ntdll!RtlpAllocateFromHeapLookaside
0905c72c 7c9101db ntdll!RtlAllocateHeap+0xeac , calling ntdll!_SEH_epilog
0905c73c 79151995 clr!SArray<DataImage::RvaInfoStructure,1>::~SArray<DataImage::RvaInfoStructure,1>+0x27 , calling clr!_EH_epilog3
0905c760 79151995 clr!SArray<DataImage::RvaInfoStructure,1>::~SArray<DataImage::RvaInfoStructure,1>+0x27 , calling clr!_EH_epilog3
...
0905c790 79170b8a clr!AssemblySpec::LoadDomainAssembly+0x389 , calling clr!_EH_epilog3_GS
...
0905c860 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
0905c880 7c9100b8 ntdll!RtlpFreeToHeapLookaside+0x22 , calling ntdll!RtlpInterlockedPushEntrySList
0905c88c 7c910041 ntdll!RtlFreeHeap+0x1e9 , calling ntdll!RtlpFreeToHeapLookaside
0905c894 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
0905c8a0 7c9100b8 ntdll!RtlpFreeToHeapLookaside+0x22 , calling ntdll!RtlpInterlockedPushEntrySList
0905c8ac 7c910041 ntdll!RtlFreeHeap+0x1e9 , calling ntdll!RtlpFreeToHeapLookaside
0905c8b4 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
...
0905c974 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
...
0905c9a8 7919c07e clr!operator delete+0x41 , calling clr!_EH_epilog3
...
0905ca08 79157057 clr!ClassLoader::LoadTypeDefThrowing+0x2f3 , calling clr!_EH_epilog3_GS
...
0905ca6c 791a7c6b clr!ClassLoader::FindClassModuleThrowing+0x190 , calling clr!_EH_epilog3_GS
0905cac4 79157057 clr!ClassLoader::LoadTypeDefThrowing+0x2f3 , calling clr!_EH_epilog3_GS
...
0905cb24 791d5ce7 clr!TypeName::GetTypeHaveAssemblyHelper+0x666 , calling clr!_EH_epilog3_catch_GS
...
0905cc30 7914f062 clr!MethodDesc::FindOrCreateAssociatedMethodDesc+0x5f , calling clr!_EH_epilog3_GS
...
0905cd98 791d5a44 clr!TypeName::Factory<InlineSString<128> >::Factory<InlineSString<128> >+0x44 , calling clr!_EH_epilog3
...
0905cdb0 791d5a44 clr!TypeName::Factory<InlineSString<128> >::Factory<InlineSString<128> >+0x44 , calling clr!_EH_epilog3
0905cde0 7916f3e8 clr!SystemDomain::GetCallersModule+0x45 , calling clr!Thread::StackWalkFrames
0905cdf0 7916f418 clr!SystemDomain::GetCallersModule+0x72 , calling clr!_EH_epilog3
0905ce34 791d5ce7 clr!TypeName::GetTypeHaveAssemblyHelper+0x666 , calling clr!_EH_epilog3_catch_GS
...
0905ce50 791d53d4 clr!TypeName::GetTypeWorker+0x1c1 , calling clr!_EH_epilog3_catch_GS
...
0905cf9c 79151995 clr!SArray<DataImage::RvaInfoStructure,1>::~SArray<DataImage::RvaInfoStructure,1>+0x27 , calling clr!_EH_epilog3
...
0905cfc4 791d59fd clr!TypeName::TypeName+0xf6 , calling clr!_EH_epilog3_GS
...
0905d08c 7914f062 clr!MethodDesc::FindOrCreateAssociatedMethodDesc+0x5f , calling clr!_EH_epilog3_GS
...
0905d0b4 79158a2d clr!MemberLoader::GetDescFromMemberDefOrRefThrowing+0x6c , calling clr!_EH_epilog3
...
0905d1a4 791505eb clr!ClassLoader::EnsureLoaded+0xd3 , calling clr!_EH_epilog3_GS
...
0905d1dc 79141ad1 clr!_EH_epilog3_GS+0xa , calling clr!__security_check_cookie
0905d1e0 7914f320 clr!SigPointer::GetTypeHandleThrowing+0x1038 , calling clr!_EH_epilog3_GS
...
0905d2e4 7914f320 clr!SigPointer::GetTypeHandleThrowing+0x1038 , calling clr!_EH_epilog3_GS
...
0905d330 791a9863 clr!Holder<Frame *,&DoNothing<Frame *>,&COMPlusCooperativeTransitionHandler,0,&CompareDefault<Frame *>,2>::~Holder<Frame *,&DoNothing<Frame *>,&COMPlusCooperativeTransitionHandler,0,&CompareDefault<Frame *>,2>+0x2b , calling clr!_EH_epilog3
0905d354 79141b19 clr!_EH_epilog3_catch_GS+0xa , calling clr!__security_check_cookie
...
0905d3fc 791a9863 clr!Holder<Frame *,&DoNothing<Frame *>,&COMPlusCooperativeTransitionHandler,0,&CompareDefault<Frame *>,2>::~Holder<Frame *,&DoNothing<Frame *>,&COMPlusCooperativeTransitionHandler,0,&CompareDefault<Frame *>,2>+0x2b , calling clr!_EH_epilog3
0905d424 791acb3e clr!CEEInfo::getArgNext+0x133 , calling clr!_EH_epilog3
...
0905d4d0 791a9863 clr!Holder<Frame *,&DoNothing<Frame *>,&COMPlusCooperativeTransitionHandler,0,&CompareDefault<Frame *>,2>::~Holder<Frame *,&DoNothing<Frame *>,&COMPlusCooperativeTransitionHandler,0,&CompareDefault<Frame *>,2>+0x2b , calling clr!_EH_epilog3
0905d4f8 791ab805 clr!CEEInfo::getCallInfo+0x13f , calling clr!_EH_epilog3
...
0905d6c0 791aa9ad clr!getMethodInfoHelper+0x29a , calling clr!_EH_epilog3_GS
...
0905d724 791ac4d4 clr!canReplaceMethodOnStack+0x154 , calling clr!_EH_epilog3
...
0905d75c 791a9863 clr!Holder<Frame *,&DoNothing<Frame *>,&COMPlusCooperativeTransitionHandler,0,&CompareDefault<Frame *>,2>::~Holder<Frame *,&DoNothing<Frame *>,&COMPlusCooperativeTransitionHandler,0,&CompareDefault<Frame *>,2>+0x2b , calling clr!_EH_epilog3
...
0905d9e8 71a916a3 wshtcpip!WSHGetSocketInformation+0x23a , calling wshtcpip!_SEH_epilog
...
0905da3c 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
...
0905da88 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
...
0905dab4 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
0905dafc 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
...
0905db40 7c911429 ntdll!RtlDeleteCriticalSection+0x83 , calling ntdll!_SEH_epilog
...
0905db74 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
0905db78 71a54230 mswsock!SockDestroySocket+0x17d , calling ntdll!RtlFreeHeap
0905db9c 71a541be mswsock!WSPCloseSocket+0x314 , calling mswsock!SockDestroySocket
0905dba0 71a541cd mswsock!WSPCloseSocket+0x329 , calling mswsock!_SEH_epilog
...
0905dfe8 7914f320 clr!SigPointer::GetTypeHandleThrowing+0x1038 , calling clr!_EH_epilog3_GS
...
0905e25c 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
...
0905e31c 7c91005d ntdll!RtlFreeHeap+0x647 , calling ntdll!_SEH_epilog
...
0905e650 7916c76d clr!COMDelegate::InternalEqualTypes+0x150 , calling clr!_EH_epilog3
0905e698 7916c76d clr!COMDelegate::InternalEqualTypes+0x150 , calling clr!_EH_epilog3
...
0905e834 79164a60 clr!CallDescrWorkerWithHandler+0x161 , calling clr!_SEH_epilog4_GS
...
0905e88c 79164a60 clr!CallDescrWorkerWithHandler+0x161 , calling clr!_SEH_epilog4_GS
...
0905ea08 791d787a clr!CallWithValueTypes_RetArgSlotWrapper+0xc2 , calling clr!_SEH_epilog4_GS
...
0905ebc4 791d787a clr!CallWithValueTypes_RetArgSlotWrapper+0xc2 , calling clr!_SEH_epilog4_GS
...
0905ee6c 7915c620 clr!SigPointer::SizeOf+0x17c , calling clr!_EH_epilog3
0905ee9c 79161987 clr!SimpleRWLock::EnterRead+0xb4 , calling clr!_EH_epilog3
...
0905eef4 7920ceae clr!DebuggerController::DispatchNativeException+0x168 , calling clr!_EH_epilog3
0905ef0c 7949b63f clr!IsIPInModule+0x89 , calling clr!_SEH_epilog4
...
0905ef34 7920ce86 clr!Debugger::FirstChanceNativeException+0x6a , calling clr!_EH_epilog3
...
0905ef6c 7920cb4e clr!CLRVectoredExceptionHandlerPhase2+0xff , calling clr!_EH_epilog3
...
0905efa4 0040e9de OurNativeSEHManangement::ProcessException <== this is our own SEH management
0905efdc 004127a5 OurNativeSEHManangement::HandleException <== this is our own SEH management
0905eff8 7c9444a8 ntdll!RtlCallVectoredExceptionHandlers+0x48
0905f018 7c933f56 ntdll!RtlDispatchException+0x19 , calling ntdll!RtlCallVectoredExceptionHandlers
...
0905f084 7915c620 clr!SigPointer::SizeOf+0x17c , calling clr!_EH_epilog3
0905f090 7c90e48a ntdll!KiUserExceptionDispatcher+0xe , calling ntdll!RtlDispatchException
0905f398 088d4da3 (MethodDesc 0871df48 +0x13 One.Of.Our.Business.Class.ProxyStateHandler(System.Object, System.EventArgs)) ====> Exception Code c0000005 cxr#905f0c4 exr#905f0a8 <================= this one is due to a NullReferenceException
...
0905f34c 7c910323 ntdll!RtlpImageNtHeader+0x56 , calling ntdll!_SEH_epilog
0905f378 7c910323 ntdll!RtlpImageNtHeader+0x56 , calling ntdll!_SEH_epilog
...
0905f380 7c812d27 kernel32!GetProcessVersion+0x12c , calling kernel32!_SEH_epilog
... HERE SOMETHING IS TRIGGERED IN OUR BUSINESS CODE
0905f404 79161f8e clr!PreStubWorker+0x165 , calling clr!_EH_epilog3
...
0905f5d8 7c912d90 ntdll!LdrUnlockLoaderLock+0xb1 , calling ntdll!_SEH_epilog
...
0905f6d4 7c80e544 kernel32!GetModuleHandleForUnicodeString+0xa0 , calling kernel32!_SEH_epilog
0905f6f4 7c80e544 kernel32!GetModuleHandleForUnicodeString+0xa0 , calling kernel32!_SEH_epilog
...
0905f6fc 7c80e6cb kernel32!BasepGetModuleHandleExW+0x250 , calling kernel32!_SEH_epilog
0905f780 7c910222 ntdll!RtlpAllocateFromHeapLookaside+0x42 , calling ntdll!_SEH_epilog
0905f7ac 7c910222 ntdll!RtlpAllocateFromHeapLookaside+0x42 , calling ntdll!_SEH_epilog
...
0905f7b4 7c9101db ntdll!RtlAllocateHeap+0xeac , calling ntdll!_SEH_epilog
0905f834 7c912d90 ntdll!LdrUnlockLoaderLock+0xb1 , calling ntdll!_SEH_epilog
...
0905fac4 7c80e6cb kernel32!BasepGetModuleHandleExW+0x250 , calling kernel32!_SEH_epilog
...
0905fb10 603b4139 mscoreei!_initptd+0x9b , calling mscoreei!_SEH_epilog4
...
0905fb1c 603b42be mscoreei!_CRT_INIT+0x161 , calling mscoreei!_SEH_epilog4
0905fb78 7c80e6cb kernel32!BasepGetModuleHandleExW+0x250 , calling kernel32!_SEH_epilog
...
0905fb90 77a817ac crypt32!I_CryptTlsDllMain+0x195 , calling crypt32!_SEH_epilog
...
0905fc40 7c91abe7 ntdll!LdrpInitializeThread+0x13b , calling ntdll!_SEH_epilog
...
*** is this line the original problem indeed ? ***
0905fca8 7c91aa5a ntdll!_LdrpInitialize+0x246 , calling ntdll!_SEH_epilog
0905fd18 7c91aa5a ntdll!_LdrpInitialize+0x246 , calling ntdll!_SEH_epilog
0905fd1c 7c90d06a ntdll!ZwContinue+0xc
0905fd20 7c90e45f ntdll!KiUserApcDispatcher+0xf , calling ntdll!ZwContinue
0905ffa0 791f59f6 clr!Thread::intermediateThreadProc+0x39 , calling clr!_alloca_probe_16
0905ffb4 7c80b729 kernel32!BaseThreadStart+0x37
The output of !clrstack:
0:023> !clrstack
OS Thread Id: 0x5d0 (23)
Child SP IP Call Site
0905f6bc 7c90e514 [GCFrame: 0905f6bc]
0905f980 7c90e514 [DebuggerU2MCatchHandlerFrame: 0905f980]
The output of k:
0:023> k
ChildEBP RetAddr
0905a004 7c90d18a ntdll!KiFastSystemCallRet
0905a008 7c8094e5 ntdll!NtCreateSection+0xc
0905a014 00000000 kernel32!CreateFileMappingW+0x10b

Related

How to switch Flux concat back to main thread?

When using Flux to concat multi publisher, if one of publisher is run on another thread, then all the value will publish on that thread instead of run on main thread, is there a way to publish all the values on main thread?
#Test
public void test() {
Flux.concat(Flux.just(3), Flux.just(1).publishOn(Schedulers.newParallel("hai")), Flux.just(2))
.collectList()
.log()
.subscribe();
}
You can see that the on next will run on thread instead of main:
####<2022-04-02 12:09:57.391> <DEBUG> <reactor.util.Loggers> <main> <> - <Using Slf4j logging framework>
####<2022-04-02 12:09:59.666> <INFO> <reactor.Mono.CollectList.1> <main> <> - <| onSubscribe([Fuseable] MonoCollectList.MonoCollectListSubscriber)>
####<2022-04-02 12:09:59.671> <INFO> <reactor.Mono.CollectList.1> <main> <> - <| request(unbounded)>
####<2022-04-02 12:09:59.678> <INFO> <reactor.Mono.CollectList.1> <hai-1> <> - <| onNext([3, 1, 2])>
####<2022-04-02 12:09:59.688> <INFO> <reactor.Mono.CollectList.1> <hai-1> <> - <| onComplete()>

How can I export console log win Elm?

It is difficult to export console.log with Elm.
I want to output the console log by pushing button like below and with console log in function. How shold I do?
sampleView : Html Message
sampleView =
Html.div (class "sample-card" :: Styles.sampleCard)
[ Html.div
(class "sample-card-list" :: Styles.sampleCardList)
[
Html.button
(class "sample-card-button" :: Styles.sampleCardListButton)
[
Html.text "サンプルボタン"
]
]
]
If I use Javascript, I want to do like below.
<button class="sample-card-button" onclick="btnClick();">サンプルボタン</button>
/* JavaScript 側 */
function btnClick() {
console.log("クリックされました");
});

If it's just for debugging, you can use Debug.log, but you can't use the Debug module in production code (running the compiler with --optimize will fail to compile if you have Debug usages). Using it can look like this:
sampleView : Html Message
sampleView =
Html.div (class "sample-card" :: Styles.sampleCard)
[ Html.div
(class "sample-card-list" :: Styles.sampleCardList)
[
Html.button
([class "sample-card-button", onClick CardButtonClicked] ++ Styles.sampleCardListButton)
[
Html.text "サンプルボタン"
]
]
]
update : Message -> Model -> ( Model, Cmd Message )
update msg model =
case msg of
CardButtonClicked ->
let
_ = Debug.log "クリックされました" msg
in
( model, Cmd.none )
If you want to write to the console in a production app, you'll need to use a port. To create a port, you'll need to update the module it's in to be declare a port module (just add port to the beginning of of the module declaration on the first line of the file).
port module Main exposing (..)
port consoleLog : String -> Cmd msg
update : Message -> Model -> ( Model, Cmd Message )
update msg model =
case msg of
CardButtonClicked ->
( model, consoleLog "クリックされました" )
Then you'll need to wire up some JavaScript to handle that port message:
var app = Elm.Main.init({ node: document.querySelector('main') })
app.ports.consoleLog.subscribe(function (msg) {
console.log(msg);
});
Here's an example app using a port to call console.log.

IM001 Driver does not support this function (ODBC)

I'm building custom ODBC driver.
my main method:
int main(int argc, char** argv) {
SQLRETURN status;
//SQLHANDLE hEnv;
//SQLHANDLE hStmt;
SQLHENV hEnv;
SQLHDBC dbc = 0;
SQLHSTMT hStmt;
SQLCHAR ConnStrOut[1024];
SQLSMALLINT x;
// startup banner
//printf();
MessageBox(GetDesktopWindow(), "ODBC Client\n\n", "Driver", MB_OK);
// show query to be executed
printf("Query: %s\n", "SELECT VISITS FROM TRAFFIC");
// allocate ENVIRONMENT
status = SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &hEnv);
// check for error
ODBC_CHK_ERROR(SQL_HANDLE_ENV, hEnv, status, "");
// set the ODBC version for behaviour expected
status = SQLSetEnvAttr(hEnv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER) SQL_OV_ODBC3, 0);
CHECK_STATUS(status, (UCHAR*)"SQLSetEnvAttr", hEnv, SQL_HANDLE_ENV);
// check for error
ODBC_CHK_ERROR(SQL_HANDLE_ENV, hEnv, status, "");
// allocate CONNECTION
status = SQLAllocHandle(SQL_HANDLE_DBC, hEnv, &dbc);
// check for error
ODBC_CHK_ERROR(SQL_HANDLE_ENV, hEnv, status, "");
// ----------- real connection takes place at this point
status = SQLDriverConnect(dbc, GetDesktopWindow(),
(unsigned char*) "DSN=myDSN",
SQL_NTS, ConnStrOut, 1024, &x,
SQL_DRIVER_PROMPT);
if (SQL_SUCCEEDED(status)) {
printf("Connected\n");
printf("Returned connection string was:\n\t%s\n", ConnStrOut);
//SQLDisconnect(dbc);
}
Everything works well when I run main using my sample client.
However, when I try odbc testing tool odbcte32 or other odbc client(s) such as SqlDbx or QTODBC, once I try to establish connection using 'myDSN' (which is using my custom driver) I always get: [Microsoft][ODBC Driver Manager] Driver does not support this function
I've properly implemented SQLDriverConnect function to create OutConnectionString by reading key-value-pairs from User DSN that uses my compiled driver DLL.
I've defined skeletons for all odbc functions http://msdn.microsoft.com/en-us/library/windows/desktop/ms714562(v=vs.85).aspx
I compile my custom diver using minGW compiler (32-bit).
I have Windows 7 OS 64-bit but I'm running 32-bit ODBC test tool.
This is driving me crazy. I don't understand which specific function is not supported in my driver. Again, I have created skeletons for all needed functions. Here's the list:
SQLAllocConnect ,
SQLAllocEnv ,
SQLAllocStmt ,
SQLAllocHandle ,
SQLFreeConnect ,
SQLFreeEnv ,
SQLFreeStmt ,
SQLBindCol ,
SQLCancel ,
SQLConnect ,
SQLDescribeCol ,
SQLDisconnect ,
SQLExecDirect ,
SQLExecute ,
SQLExtendedFetch ,
SQLFetch ,
SQLGetCursorName ,
SQLNumResultCols ,
SQLPrepare ,
SQLRowCount ,
SQLSetCursorName ,
SQLColumns ,
SQLDriverConnect ,
SQLGetData ,
SQLGetInfo ,
SQLGetTypeInfo ,
SQLParamData ,
SQLPutData ,
SQLStatistics ,
SQLTables ,
SQLBrowseConnect ,
SQLColumnPrivileg,
SQLDescribeParam ,
SQLForeignKeys ,
SQLMoreResults ,
SQLNativeSql ,
SQLNumParams ,
SQLPrimaryKeys ,
SQLProcedureColum,
SQLProcedures ,
SQLSetPos ,
SQLTablePrivilege,
SQLBindParameter ,
SQLCloseCursor ,
SQLColAttribute ,
SQLCopyDesc ,
SQLEndTran ,
SQLFetchScroll ,
SQLFreeHandle ,
SQLGetConnectAttr,
SQLGetDescField ,
SQLGetDescRec ,
SQLGetDiagField ,
SQLGetDiagRec ,
SQLGetEnvAttr ,
SQLGetStmtAttr ,
SQLSetConnectAttr,
SQLSetDescField ,
SQLSetDescRec ,
SQLSetEnvAttr ,
SQLSetStmtAttr ,
SQLBulkOperations,
SQLSpecialColumns.
EDIT:
Figured it out. SQLDisconnect was defined incorrectly. Make sure all parameters that are passed are correct.
The right definition was:
RETCODE SQL_API SQLDisconnect(SQLHDBC pHandle) {
__CHK_HANDLE(pHandle, SQL_HANDLE_DBC, SQL_ERROR);
_SQLFreeDiag(_DIAGCONN(pHandle));
_SQLDisconnect((PGENODBCCONN) pHandle);
return (SQL_SUCCESS);
}
The way I figured it out:
create .def file (name it the same as your driver DLL file name, i.e. in my case it was axodbc.def), list all functions present in your driver in it, as following:
LIBRARY axodbc
DESCRIPTION "Driver 1 definitions"
EXPORTS
SQLAllocConnect
SQLAllocEnv
SQLAllocStmt
SQLAllocHandle
SQLFreeConnect
SQLFreeEnv
SQLFreeStmt
SQLBindCol
SQLCancel
SQLConnect
SQLDescribeCol
SQLExecDirect
SQLExecute
SQLDisconnect
SQLExtendedFetch
SQLFetch
SQLGetCursorName
SQLNumResultCols
SQLPrepare
SQLRowCount
SQLSetCursorName
SQLColumns
SQLDriverConnect
SQLGetData
SQLGetInfo
SQLGetTypeInfo
SQLParamData
SQLPutData
SQLStatistics
SQLTables
SQLBrowseConnect
SQLColumnPrivileges
SQLDescribeParam
SQLForeignKeys
SQLMoreResults
SQLNativeSql
SQLNumParams
SQLPrimaryKeys
SQLProcedureColumns
SQLProcedures
SQLSetPos
SQLTablePrivileges
SQLBindParameter
SQLCloseCursor
SQLColAttribute
SQLCopyDesc
SQLEndTran
SQLFetchScroll
SQLFreeHandle
SQLGetConnectAttr
SQLGetDescField
SQLGetDescRec
SQLGetDiagField
SQLGetDiagRec
SQLGetEnvAttr
SQLGetStmtAttr
SQLSetConnectAttr
SQLSetDescField
SQLSetDescRec
SQLSetEnvAttr
SQLSetStmtAttr
SQLBulkOperations
SQLSpecialColumns
Compile DLL (using mingw (g++)) and include your .def file, something like:
g++ -shared -o axodbc.dll axodbc.cpp connectionmanager.cpp diagnostics.cpp myresources.res axodbc.def -lodbc32 -lodbccp32
Compiler gave me an error at this point that SQLDisconnect was defined incorrectly

I don't SQLGetFunctions in that list. You can always enable ODBC tracing in the driver manager and it will show what ODBC calls are made and what the result was.

NSSreamstatus if i am getting data or not

I have NSInputStream , i want to check if i am getting data from other end , i read the NSStreamStatus , i cam across that "NSStreamStatusReading" is use to check the read data .
I tried to check that status but its not working can any one tell me how to check if i am getting data or not
..
code:
if([inputStream streamStatus]==NSStreamStatusReading)
{
NSlog(#"server is sending");
}
else
{
NSlog(#"no");
}
its working when its sending but when i stop server , its not updating .

NSManaged object sometimes is null and causes crash

I am using coredata and often my app crashes because one of the properties of a managed object turn out null. For example when i set text of a UILabel to a text property of the managed object it displays NULL
To find the problem I overrode the setter which assigns the NSManagedObject to a instance variable. In the setter I use NSLog to print the object:
NSLog(#"TSC: setting segment: %#", segment);
its output:
2012-11-05 21:01:56.758 JetLagged[4505:907] TSC: setting segment: <Segment: 0x1d0ab790> (entity: Segment; id: 0x1d0a7f60 <x-coredata://BF6F2D98-0658-4005-8BEF-9FE6B398AF86/Segment/p8> ; data: {
arrivalDate = "2012-11-11 05:00:17 +0000";
arrivalLeg = "0x1d0abba0 <x-coredata://BF6F2D98-0658-4005-8BEF-9FE6B398AF86/IteneryLeg/p11>";
departureDate = "2012-11-10 19:00:17 +0000";
departureLeg = "0x1d0abba0 <x-coredata://BF6F2D98-0658-4005-8BEF-9FE6B398AF86/IteneryLeg/p11>";
iteneryLegs = (
"0x1d0abba0 <x-coredata://BF6F2D98-0658-4005-8BEF-9FE6B398AF86/IteneryLeg/p11>"
);
trip = "0x1c58add0 <x-coredata://BF6F2D98-0658-4005-8BEF-9FE6B398AF86/Trip/p5>";
})
All looks fine, however app still displayes null in some places or crashes. I catch the problem I added some NSAsserts and when I ran the code below in the same run as the output above it failed the assertion. Here is the assert code (segmentToCheck is segment from above).
NSSet *legs = [segmentToCheck valueForKey:#"iteneryLegs"];
NSAssert([legs count] != 0, #"Error: nolegs %#", legs);
its output:
2012-11-05 21:01:56.763 JetLagged[4505:907] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error: nolegs (null)'
When i run the app again (without any data modification) it works fine. Any idea what it might be?

Looks like a typo: #"itineryLegs" instead of #"iteneryLegs".

We Keep Coding

sql objective-c vba vb.net react-native apache vue.js tensorflow api pandas

What is ntdll!_SEH_epilog ? Is the first occurence of it the place where the real issue is? - native

Related

How to switch Flux concat back to main thread?

How can I export console log win Elm?

IM001 Driver does not support this function (ODBC)

NSSreamstatus if i am getting data or not

NSManaged object sometimes is null and causes crash

Categories

Resources