So, I finally checked it and it works without any problem. Some people with older ReSharper 3 builds report weird problems, like "Find in files" crashing, but I couldn't reproduce it with latest ReSharper 3 EAP build.
TF> You're soooo slow ;) TF> TF> Just kidding, take your time. Though I bet everyone's eagerly TF> awaiting it :-P TF> TF> Best regard TF> Thomas TF> "Ilya Ryzhenkov" <orangy@jetbrains.com> wrote in message TF> news:76a2bd0b1491bf8c9f9d647d53b98@news.intellij.net... TF> >> Hello Thomas, >> >> We just downloaded it and installing. We will verify this in the >> couple of days. >> >> Sincerely, >> Ilya Ryzhenkov >> JetBrains, Inc >> http://www.jetbrains.com >> "Develop with pleasure!" >> TF> Now that VS2008 is officially released: is the most recent EAP >> build >> TF> compatible with VS2008 RTM? >> TF>
We are in just a bit different time zone ;) So, I finally checked it and it works without any problem. Some people with older ReSharper 3 builds report weird problems, like "Find in files" crashing, but I couldn't reproduce it with latest ReSharper 3 EAP build.
I have run the uninstaller on all R# that appear in add/remove programs including the VS2005 one, as part of the process of identifying that it was R# that was the addin that was causing the problem, and for each version I've tried I've uninstalled the existing one 1st.
R# is for VS2008 the only VS addin installed at the moment and I still get the problem. it only seems to be affecting my XP\X64 machine and not the Vista X86 or the Vista X64 machine.
I've put all the info in the RSRP-53220 bug in Jira.
thank you, I've noticed your comment to the request. It would be nice if you try to attach a debugger to VS prior to opening the Find in Files dialog, set break on any exception, and then try to open dialog - probably this will help to reveal the origin of the crash. Thanks.
I have run the uninstaller on all R# that appear in add/remove programs including the VS2005 one, as part of the process of identifying that it was R# that was the addin that was causing the problem, and for each version I've tried I've uninstalled the existing one 1st.
R# is for VS2008 the only VS addin installed at the moment and I still get the problem. it only seems to be affecting my XP\X64 machine and not the Vista X86 or the Vista X64 machine.
I've put all the info in the RSRP-53220 bug in Jira.
>> Hello, >> >>> That hasn't worked for me - I still get the find in files crashing >>> in this build: >>> >> Are you sure you have no conflicting R# installations on the same >> machine? >> >> If there's more than one R# 3.x installed (whatever VS version), they >> all must be of the same exactly version. >> >> - >> Serge Baltic >> JetBrains, Inc - http://www.jetbrains.com >> "Develop with pleasure!"
Could you please take a stack trace shot with symbols like “ntdll.dll!7728a08a()” resolved? That could be done by specifying a Symbol Server at the Debug options in Visual Studio. However, it's going to download quite a load of PDBs for system DLLs involved … takes some time and traffic.
Also, seems like it's native-only debugging mode stack trace, as mscorwks and System.ni would usually result in .NET stack frames. Mixed-mode debugging stack trace would be more interesting.
Can you give us some tips on how best to obtain a mixed-mode debugging stack trace so we can send the results to you? The reason I ask is because I see the dialog proclaiming Visual Studio 2005 crashed, I click OK and it restarts. I assume I need to attach windbg to Visual Studio 2005 before I dismiss the dialog to obtain a stack trace or a crash dump.
I just realized I don't have Debugging Tools for Windows installed since I repaved my notebook with Vista, so I'm off to download the package and setup the symbol server.
Could you please take a stack trace shot with symbols like “ntdll.dll!7728a08a()” resolved? That could be done by specifying a Symbol Server at the Debug options in Visual Studio. However, it's going to download quite a load of PDBs for system DLLs involved … takes some time and traffic.
>
Also, seems like it's native-only debugging mode stack trace, as mscorwks and System.ni would usually result in .NET stack frames. Mixed-mode debugging stack trace would be more interesting.
Can you give us some tips on how best to obtain a mixed-mode debugging stack trace so we can send the results to you?
I just realized I don't have Debugging Tools for Windows installed
Well, Visual Studio itself is just enough, no Debugging Tools or special symbol servers needed for that.
If the crash dialog suggests that you debug the faulty application, you can choose the Debug option, selecting any VS not below 8.0 and setting the “Manually choose the debugging engines” checkbox, going then for Native and Managed debugging.
If it's just “Send, Close or Restart”, then you could attach another VS instance to the one you're about to close before you actually close it (choosing the debugging engines as needed). In this case the attached VS would break debugging when the first one crashes on exit, and there will be the stacktrace.
VS itself is capable of pulling PDBs from the Symbol Server, there's a page for it in the Options dialog, and the exact URL to write down into the page is available if you press the Help button and follow some link on that help page.
Could you please take a stack trace shot with symbols like “ntdll.dll!7728a08a()” resolved? That could be done by specifying a Symbol Server at the Debug options in Visual Studio. However, it's going to download quite a load of PDBs for system DLLs involved … takes some time and traffic.
>
Also, seems like it's native-only debugging mode stack trace, as mscorwks and System.ni would usually result in .NET stack frames. Mixed-mode debugging stack trace would be more interesting.
In the stack trace you see a call to closesocket, followed by several calls inside nvappfilter. That library belongs to the NVIDIA ForceWare Network Access Manager, a firewall application leveraging NVIDIA´s NIC. So I uninstalled the Network Access Manager, and afterwards VS2K8 didn´t crash anymore when closing it.
So I guess that your network license check somehow interferes with the firewall software. Dunno who I should blame, but Google revealed that there's for instance an issue with the Network Access Manager and µTorrent.
Anyway, everything´s working fine now, and I don´t think I´m gonna miss the Network Access Manager ;)
>> Hello, >> >> Could you please take a stack trace shot with symbols like >> “ntdll.dll!7728a08a()” resolved? That could be done by specifying a >> Symbol Server at the Debug options in Visual Studio. However, it's going >> to download quite a load of PDBs for system DLLs involved … takes some >> time and traffic. >> >> Also, seems like it's native-only debugging mode stack trace, as mscorwks >> and System.ni would usually result in .NET stack frames. Mixed-mode >> debugging stack trace would be more interesting. >> >> — >> Serge Baltic >> JetBrains, Inc — http://www.jetbrains.com >> “Develop with pleasure!” >> >>
I were going to write that I see no conclusions immediately occuring from the stack trace but for some heap corruption. Luckily you tracked down the strange unresolved DLL from the stack trace.
Can't be sure whether it's because of R# or that driver … The quality of the drivers, hmp, varies that much nowdays. Also, the DEVENV process has its caveats — unmanaged code, .NET vs unmanaged interaction, and such. Would have been much simpler with a fully-managed app. I doubt it's about R# networking, as it's all managed; I'd rather blame some interop with unmanaged code that could at times result in random memory corruption.
I'm glad it helped to see the stack traces, anyway :)
we experience a similar problem with the Find dialog.
I've hit "Debug" when Visual Studio crashed and it loaded the symbols from the symbol server. But it didn't load the symbols for msenv.dll for some reason, so the stacktrace is not really readable.
thank you, I've noticed your comment to the request. It would be nice if you try to attach a debugger to VS prior to opening the Find in Files dialog, set break on any exception, and then try to open dialog - probably this will help to reveal the origin of the crash. Thanks.
> > > >> I have run the uninstaller on all R# that appear in add/remove >> programs including the VS2005 one, as part of the process of >> identifying that it was R# that was the addin that was causing the >> problem, and for each version I've tried I've uninstalled the existing >> one 1st. >> >> R# is for VS2008 the only VS addin installed at the moment and I still >> get the problem. it only seems to be affecting my XP\X64 machine and >> not the Vista X86 or the Vista X64 machine. >> >> I've put all the info in the RSRP-53220 bug in Jira. >> >> "Serge Baltic" <baltic@intellij.net> wrote in message >> news:dc0986bf78b1e8c9fa9e699c6768@news.intellij.net... >> >>> Hello, >>> >>>> That hasn't worked for me - I still get the find in files crashing >>>> in this build: >>>> >>> Are you sure you have no conflicting R# installations on the same >>> machine? >>> >>> If there's more than one R# 3.x installed (whatever VS version), they >>> all must be of the same exactly version. >>> >>> - >>> Serge Baltic >>> JetBrains, Inc - http://www.jetbrains.com >>> "Develop with pleasure!" >
we experience a similar problem with the Find dialog.
I've hit "Debug" when Visual Studio crashed and it loaded the symbols from the symbol server. But it didn't load the symbols for msenv.dll for some reason, so the stacktrace is not really readable.
>> Hello Mark, >> >> thank you, I've noticed your comment to the request. It would be nice >> if >> you try to attach a debugger to VS prior to opening the Find in Files >> dialog, >> set break on any exception, and then try to open dialog - probably >> this >> will help to reveal the origin of the crash. Thanks. >> Dmitry Shaporenkov >> JetBrains, Inc >> http://www.jetbrains.com >> "Develop with pleasure!" >>> I have run the uninstaller on all R# that appear in add/remove >>> programs including the VS2005 one, as part of the process of >>> identifying that it was R# that was the addin that was causing the >>> problem, and for each version I've tried I've uninstalled the >>> existing one 1st. >>> >>> R# is for VS2008 the only VS addin installed at the moment and I >>> still get the problem. it only seems to be affecting my XP\X64 >>> machine and not the Vista X86 or the Vista X64 machine. >>> >>> I've put all the info in the RSRP-53220 bug in Jira. >>> >>> "Serge Baltic" <baltic@intellij.net> wrote in message >>> news:dc0986bf78b1e8c9fa9e699c6768@news.intellij.net... >>> >>>> Hello, >>>> >>>>> That hasn't worked for me - I still get the find in files crashing >>>>> in this build: >>>>> >>>> Are you sure you have no conflicting R# installations on the same >>>> machine? >>>> >>>> If there's more than one R# 3.x installed (whatever VS version), >>>> they all must be of the same exactly version. >>>> >>>> - >>>> Serge Baltic >>>> JetBrains, Inc - http://www.jetbrains.com >>>> "Develop with pleasure!"
> > > >> Hi Dmitry, >> >> we experience a similar problem with the Find dialog. >> >> I've hit "Debug" when Visual Studio crashed and it loaded the symbols >> from the symbol server. But it didn't load the symbols for msenv.dll >> for some reason, so the stacktrace is not really readable. >> >> Any clues why this might be? >> >> Kind regards, >> Henning >> "Dmitry Shaporenkov" <dsha@jetbrains.com> wrote in message >> news:c8a8a0be28178c9fbf187b5af11@news.intellij.net... >> >>> Hello Mark, >>> >>> thank you, I've noticed your comment to the request. It would be nice >>> if >>> you try to attach a debugger to VS prior to opening the Find in Files >>> dialog, >>> set break on any exception, and then try to open dialog - probably >>> this >>> will help to reveal the origin of the crash. Thanks. >>> Dmitry Shaporenkov >>> JetBrains, Inc >>> http://www.jetbrains.com >>> "Develop with pleasure!" >>>> I have run the uninstaller on all R# that appear in add/remove >>>> programs including the VS2005 one, as part of the process of >>>> identifying that it was R# that was the addin that was causing the >>>> problem, and for each version I've tried I've uninstalled the >>>> existing one 1st. >>>> >>>> R# is for VS2008 the only VS addin installed at the moment and I >>>> still get the problem. it only seems to be affecting my XP\X64 >>>> machine and not the Vista X86 or the Vista X64 machine. >>>> >>>> I've put all the info in the RSRP-53220 bug in Jira. >>>> >>>> "Serge Baltic" <baltic@intellij.net> wrote in message >>>> news:dc0986bf78b1e8c9fa9e699c6768@news.intellij.net... >>>> >>>>> Hello, >>>>> >>>>>> That hasn't worked for me - I still get the find in files crashing >>>>>> in this build: >>>>>> >>>>> Are you sure you have no conflicting R# installations on the same >>>>> machine? >>>>> >>>>> If there's more than one R# 3.x installed (whatever VS version), >>>>> they all must be of the same exactly version. >>>>> >>>>> - >>>>> Serge Baltic >>>>> JetBrains, Inc - http://www.jetbrains.com >>>>> "Develop with pleasure!" >
>> Hello Henning, >> >> what version of Windows you're running on? >> >> Thanks. >> >> >> Dmitry Shaporenkov >> JetBrains, Inc >> http://www.jetbrains.com >> "Develop with pleasure!" >> >> >> >>> Hi Dmitry, >>> >>> we experience a similar problem with the Find dialog. >>> >>> I've hit "Debug" when Visual Studio crashed and it loaded the symbols >>> from the symbol server. But it didn't load the symbols for msenv.dll >>> for some reason, so the stacktrace is not really readable. >>> >>> Any clues why this might be? >>> >>> Kind regards, >>> Henning >>> "Dmitry Shaporenkov" <dsha@jetbrains.com> wrote in message >>> news:c8a8a0be28178c9fbf187b5af11@news.intellij.net... >>> >>>> Hello Mark, >>>> >>>> thank you, I've noticed your comment to the request. It would be nice >>>> if >>>> you try to attach a debugger to VS prior to opening the Find in Files >>>> dialog, >>>> set break on any exception, and then try to open dialog - probably >>>> this >>>> will help to reveal the origin of the crash. Thanks. >>>> Dmitry Shaporenkov >>>> JetBrains, Inc >>>> http://www.jetbrains.com >>>> "Develop with pleasure!" >>>>> I have run the uninstaller on all R# that appear in add/remove >>>>> programs including the VS2005 one, as part of the process of >>>>> identifying that it was R# that was the addin that was causing the >>>>> problem, and for each version I've tried I've uninstalled the >>>>> existing one 1st. >>>>> >>>>> R# is for VS2008 the only VS addin installed at the moment and I >>>>> still get the problem. it only seems to be affecting my XP\X64 >>>>> machine and not the Vista X86 or the Vista X64 machine. >>>>> >>>>> I've put all the info in the RSRP-53220 bug in Jira. >>>>> >>>>> "Serge Baltic" <baltic@intellij.net> wrote in message >>>>> news:dc0986bf78b1e8c9fa9e699c6768@news.intellij.net... >>>>> >>>>>> Hello, >>>>>> >>>>>>> That hasn't worked for me - I still get the find in files crashing >>>>>>> in this build: >>>>>>> >>>>>> Are you sure you have no conflicting R# installations on the same >>>>>> machine? >>>>>> >>>>>> If there's more than one R# 3.x installed (whatever VS version), >>>>>> they all must be of the same exactly version. >>>>>> >>>>>> - >>>>>> Serge Baltic >>>>>> JetBrains, Inc - http://www.jetbrains.com >>>>>> "Develop with pleasure!" >> >>
Hello Thomas,
We just downloaded it and installing. We will verify this in the couple of
days.
Sincerely,
Ilya Ryzhenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
TF> Now that VS2008 is officially released: is the most recent EAP build
TF> compatible with VS2008 RTM?
TF>
You're soooo slow ;)
Just kidding, take your time. Though I bet everyone's eagerly awaiting it
:-P
Best regard
Thomas
"Ilya Ryzhenkov" <orangy@jetbrains.com> wrote in message
news:76a2bd0b1491bf8c9f9d647d53b98@news.intellij.net...
>
>
>
>
>
"Thomas Freudenberg" <info@thomasfreudenberg.com> schrieb
>
For me it works. Using it with Beta 2, RC and RTM.
Regards
Albert
Hello Thomas,
We are in just a bit different time zone ;)
So, I finally checked it and it works without any problem. Some people with
older ReSharper 3 builds report weird problems, like "Find in files" crashing,
but I couldn't reproduce it with latest ReSharper 3 EAP build.
Sincerely,
Ilya Ryzhenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
TF> You're soooo slow ;)
TF>
TF> Just kidding, take your time. Though I bet everyone's eagerly
TF> awaiting it :-P
TF>
TF> Best regard
TF> Thomas
TF> "Ilya Ryzhenkov" <orangy@jetbrains.com> wrote in message
TF> news:76a2bd0b1491bf8c9f9d647d53b98@news.intellij.net...
TF>
>> Hello Thomas,
>>
>> We just downloaded it and installing. We will verify this in the
>> couple of days.
>>
>> Sincerely,
>> Ilya Ryzhenkov
>> JetBrains, Inc
>> http://www.jetbrains.com
>> "Develop with pleasure!"
>> TF> Now that VS2008 is officially released: is the most recent EAP
>> build
>> TF> compatible with VS2008 RTM?
>> TF>
That hasn't worked for me - I still get the find in files crashing in this
build:
30 Oct 2007 - build 548 (VS9)
I'll try with last nights untested and see if that makes any difference
"Ilya Ryzhenkov" <orangy@jetbrains.com> wrote in message
news:76a2bd0b1492c28c9fa55fb1e6dac@news.intellij.net...
>
Hello,
Are you sure you have no conflicting R# installations on the same machine?
If there's more than one R# 3.x installed (whatever VS version), they all
must be of the same exactly version.
—
Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”
I tried both builds 561 and 563, and VS2K8 crashes each time I close it.
Bummer :(
Regards
Thomas
"Albert Weinert" <newsh2-06@der-albert.com> wrote in message
news:fhvli8$67c$1@is.intellij.net...
>
>
>> You're soooo slow ;)
>>
>> Just kidding, take your time. Though I bet everyone's eagerly awaiting it
>> :-P#
>
>
>
"Thomas Freudenberg" <info@thomasfreudenberg.com> schrieb im Newsbeitrag
news:fi22js$dmb$1@is.intellij.net...
>I tried both builds 561 and 563, and VS2K8 crashes each time I close it.
>Bummer :(
Don't close it over the X-Button in the Title Bar :(
Regards
Albert
Thanks, Albert. However, it crashes even if I close it via File -> Exit :(
Regards
Thomas
"Albert Weinert" <newsh2-06@der-albert.com> wrote in message
news:fi2cdk$pup$1@is.intellij.net...
>
>
>>I tried both builds 561 and 563, and VS2K8 crashes each time I close it.
>>Bummer :(
>
>
>
"Thomas Freudenberg" <info@thomasfreudenberg.com> schrieb im Newsbeitrag
news:fi2d4k$4ud$1@is.intellij.net...
That's sad.
http://www.jetbrains.net/jira/browse/RSRP-51553
"They" say, the can't reproduce. Even i cannot :) Sometimes it simply
happens.
Regards
Albert
Hello,
What are the stack traces of the crash?
—
Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”
I have run the uninstaller on all R# that appear in add/remove programs
including the VS2005 one, as part of the process of identifying that it was
R# that was the addin that was causing the problem, and for each version
I've tried I've uninstalled the existing one 1st.
R# is for VS2008 the only VS addin installed at the moment and I still get
the problem. it only seems to be affecting my XP\X64 machine and not the
Vista X86 or the Vista X64 machine.
I've put all the info in the RSRP-53220 bug in Jira.
"Serge Baltic" <baltic@intellij.net> wrote in message
news:dc0986bf78b1e8c9fa9e699c6768@news.intellij.net...
>
>> That hasn't worked for me - I still get the find in files crashing in
>> this build:
>
>
>
>
Hello Mark,
thank you, I've noticed your comment to the request. It would be nice if
you try to attach a debugger to VS prior to opening the Find in Files dialog,
set break on any exception, and then try to open dialog - probably this will
help to reveal the origin of the crash. Thanks.
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>> Hello,
>>
>>> That hasn't worked for me - I still get the find in files crashing
>>> in this build:
>>>
>> Are you sure you have no conflicting R# installations on the same
>> machine?
>>
>> If there's more than one R# 3.x installed (whatever VS version), they
>> all must be of the same exactly version.
>>
>> -
>> Serge Baltic
>> JetBrains, Inc - http://www.jetbrains.com
>> "Develop with pleasure!"
Unfortunately, there's no mention of ReSharper:
ntdll.dll!771f0004()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!77257ae0()
ntdll.dll!7728a08a()
ntdll.dll!7728a110()
ntdll.dll!772300c4()
ntdll.dll!77291d05()
ntdll.dll!7721b6d1()
ntdll.dll!7721b6a3()
ntdll.dll!7721b648()
ntdll.dll!771fee57()
mscorwks.dll!79e718ab()
mscorwks.dll!79e790ca()
mscorwks.dll!79f034f5()
System.ni.dll!7a5ca74e()
System.ni.dll!7a60648a()
System.ni.dll!7a6065c3()
System.ni.dll!7a5fe56b()
System.ni.dll!7a60f35b()
System.ni.dll!7a60f3a1()
System.ni.dll!7a60f31a()
mscorwks.dll!79f0462c()
mscorwks.dll!79f62ac8()
mscorwks.dll!79e8bcd7()
mscorwks.dll!79e8bcb6()
msenv.dll!6f72c232()
msenv.dll!6f72c232()
msenv.dll!6f72c0d6()
msenv.dll!6f72ad6a()
msenv.dll!6f72aad2()
msenv.dll!6f613148()
msenv.dll!6f613087()
msenv.dll!6f61306f()
msenv.dll!6f61292f()
msenv.dll!6f60700e()
kernel32.dll!754c1d27()
msenv.dll!6f510fe2()
msenv.dll!6f5ad7d4()
msenv.dll!6f5b5b91()
msenv.dll!6f5b5b21()
msenv.dll!6f5b5abc()
msenv.dll!6f5b5a8b()
msenv.dll!6f5af99e()
msenv.dll!6f5b3b2d()
devenv.exe!2fc9a4a6()
devenv.exe!2fc97301()
advapi32.dll!76a760ce()
advapi32.dll!76a7610c()
advapi32.dll!76a7663c()
ntdll.dll!7722a7a2()
advapi32.dll!76a7649d()
advapi32.dll!76a76578()
advapi32.dll!76a76578()
devenv.exe!2fc91d09()
kernel32.dll!754c19f1()
ntdll.dll!7725d109()
However, it doesn't crash if I uninstall ReSharper.
Regards
-Thomas
"Serge Baltic" <baltic@intellij.net> wrote in message
news:dc0986bf78f188c9fb8d1ec901cc@news.intellij.net...
>
>> I tried both builds 561 and 563, and VS2K8 crashes each time I close
>> it. Bummer :(
>
>
>
Hello,
Could you please take a stack trace shot with symbols like “ntdll.dll!7728a08a()”
resolved? That could be done by specifying a Symbol Server at the Debug options
in Visual Studio. However, it's going to download quite a load of PDBs for
system DLLs involved … takes some time and traffic.
Also, seems like it's native-only debugging mode stack trace, as mscorwks
and System.ni would usually result in .NET stack frames. Mixed-mode debugging
stack trace would be more interesting.
—
Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”
Can you give us some tips on how best to obtain a mixed-mode debugging stack
trace so we can send the results to you? The reason I ask is because I see
the dialog proclaiming Visual Studio 2005 crashed, I click OK and it
restarts. I assume I need to attach windbg to Visual Studio 2005 before I
dismiss the dialog to obtain a stack trace or a crash dump.
I just realized I don't have Debugging Tools for Windows installed since I
repaved my notebook with Vista, so I'm off to download the package and setup
the symbol server.
"Serge Baltic" <baltic@intellij.net> wrote in message
news:dc0986bf793148c9fcd57b1bdbab@news.intellij.net...
>
>
>
>
Hello,
Well, Visual Studio itself is just enough, no Debugging Tools or special
symbol servers needed for that.
If the crash dialog suggests that you debug the faulty application, you can
choose the Debug option, selecting any VS not below 8.0 and setting the “Manually
choose the debugging engines” checkbox, going then for Native and Managed
debugging.
If it's just “Send, Close or Restart”, then you could attach another VS instance
to the one you're about to close before you actually close it (choosing the
debugging engines as needed). In this case the attached VS would break debugging
when the first one crashes on exit, and there will be the stacktrace.
VS itself is capable of pulling PDBs from the Symbol Server, there's a page
for it in the Options dialog, and the exact URL to write down into the page
is available if you press the Help button and follow some link on that help
page.
—
Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”
Ok, here you go:
ntdll.dll!_RtlReportException@12() + 0x51 bytes
ntdll.dll!_RtlpTerminateFailureFilter@8() + 0x14 bytes
ntdll.dll!_RtlReportCriticalFailure@8() + 0x70 bytes
ntdll.dll!@_EH4_CallFilterFunc@8() + 0x12 bytes
ntdll.dll!ExecuteHandler2@20() + 0x26 bytes
ntdll.dll!ExecuteHandler@20() + 0x24 bytes
ntdll.dll!_KiUserExceptionDispatcher@8() + 0xf bytes
ntdll.dll!_RtlReportCriticalFailure@8() + 0x5b bytes
ntdll.dll!_RtlpReportHeapFailure@4() + 0x21 bytes
ntdll.dll!_RtlpLogHeapFailure@24() + 0xab bytes
ntdll.dll!_RtlFreeHeap@12() + 0x35677 bytes
kernel32.dll!_HeapFree@12() + 0x14 bytes
nvappfilter.dll!11ba4f7c()
[Frames below may be incorrect and/or missing, no symbols loaded for
nvappfilter.dll]
nvappfilter.dll!11ba5698()
nvappfilter.dll!11ba5d86()
nvappfilter.dll!11ba662e()
ws2_32.dll!_closesocket@4() + 0x4a bytes
mscorwks.dll!_CallDescrWorker@20() + 0x1f bytes
mscorwks.dll!_CallDescrWorkerWithHandler@24() + 0x9f bytes
mscorwks.dll!MethodDesc::CallDescr() + 0x15a bytes
mscorwks.dll!MethodDesc::CallTargetWorker() + 0x1f bytes
mscorwks.dll!MethodDescCallSite::Call_RetLPVOID() + 0x1c bytes
mscorwks.dll!SafeHandle::RunReleaseMethod() + 0x89 bytes
mscorwks.dll!SafeHandle::Release() + 0x433 bytes
mscorwks.dll!SafeHandle::DangerousRelease() + 0x9a bytes
System.ni.dll!7a5ca74e()
System.ni.dll!7a60648a()
System.ni.dll!7a6065c3()
System.ni.dll!7a5fe56b()
System.ni.dll!7a60f35b()
System.ni.dll!7a60f3a1()
System.ni.dll!7a60f31a()
mscorwks.dll!COMToCLRWorkerDebuggerWrapper() + 0x37 bytes
mscorwks.dll!_COMToCLRWorker@8() + 0x5e876 bytes
027ba235()
msenv.dll!6a1dc232()
msenv.dll!6a1dc0d6()
msenv.dll!6a1dad6a()
msenv.dll!6a1daad2()
msenv.dll!6a0c3148()
msenv.dll!6a0c3087()
msenv.dll!6a0c306f()
msenv.dll!6a0c292f()
msenv.dll!6a0b700e()
ntdll.dll!_NtCallbackReturn@12() + 0x12 bytes
user32.dll!___fnDWORD@4() + 0x3e bytes
ntdll.dll!_KiUserCallbackDispatcher@12() + 0x2e bytes
user32.dll!_CallNextHookEx@16() + 0x33f4b bytes
073b08ab()
user32.dll!_DispatchHookA@16() + 0x56 bytes
user32.dll!_fnHkINLPCWPRETSTRUCTA@24() + 0x79 bytes
user32.dll!___fnDWORD@4() + 0x2b bytes
ntdll.dll!_KiUserCallbackDispatcher@12() + 0x2e bytes
user32.dll!_RealDefWindowProcWorker@24() + 0x42c bytes
fffdb800()
uxtheme.dll!DoMsgDefault() + 0x29 bytes
uxtheme.dll!_ThemeDefWindowProc() + 0xf2 bytes
mshtml.dll!CFlowLayout::CalcSizeSearch() + 0x12f bytes
"Serge Baltic" <baltic@intellij.net> wrote in message
news:dc0986bf793148c9fcd57b1bdbab@news.intellij.net...
>
>
>
>
Finally I was able to track down this issue.
In the stack trace you see a call to closesocket, followed by several calls
inside nvappfilter. That library belongs to the NVIDIA ForceWare Network
Access Manager, a firewall application leveraging NVIDIA´s NIC. So I
uninstalled the Network Access Manager, and afterwards VS2K8 didn´t crash
anymore when closing it.
So I guess that your network license check somehow interferes with the
firewall software. Dunno who I should blame, but Google revealed that
there's for instance an issue with the Network Access Manager and µTorrent.
Anyway, everything´s working fine now, and I don´t think I´m gonna miss the
Network Access Manager ;)
Regards
-Thomas
"Thomas Freudenberg" <info@thomasfreudenberg.com> wrote in message
news:fifolg$l7u$1@is.intellij.net...
>
>> ntdll.dll!_DbgBreakPoint@0()
>
>
>
>> Hello,
>>
>> Could you please take a stack trace shot with symbols like
>> “ntdll.dll!7728a08a()” resolved? That could be done by specifying a
>> Symbol Server at the Debug options in Visual Studio. However, it's going
>> to download quite a load of PDBs for system DLLs involved … takes some
>> time and traffic.
>>
>> Also, seems like it's native-only debugging mode stack trace, as mscorwks
>> and System.ni would usually result in .NET stack frames. Mixed-mode
>> debugging stack trace would be more interesting.
>>
>> —
>> Serge Baltic
>> JetBrains, Inc — http://www.jetbrains.com
>> “Develop with pleasure!”
>>
>>
Hello,
Sounds great :)
I were going to write that I see no conclusions immediately occuring from
the stack trace but for some heap corruption. Luckily you tracked down the
strange unresolved DLL from the stack trace.
Can't be sure whether it's because of R# or that driver … The quality of
the drivers, hmp, varies that much nowdays. Also, the DEVENV process has
its caveats — unmanaged code, .NET vs unmanaged interaction, and such. Would
have been much simpler with a fully-managed app. I doubt it's about R# networking,
as it's all managed; I'd rather blame some interop with unmanaged code that
could at times result in random memory corruption.
I'm glad it helped to see the stack traces, anyway :)
—
Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”
Hi Dmitry,
we experience a similar problem with the Find dialog.
I've hit "Debug" when Visual Studio crashed and it loaded the symbols from
the symbol server. But it didn't load the symbols for msenv.dll for some
reason, so the stacktrace is not really readable.
Any clues why this might be?
Kind regards,
Henning
"Dmitry Shaporenkov" <dsha@jetbrains.com> wrote in message
news:c8a8a0be28178c9fbf187b5af11@news.intellij.net...
>
>
>
>
>
>
>> I have run the uninstaller on all R# that appear in add/remove
>> programs including the VS2005 one, as part of the process of
>> identifying that it was R# that was the addin that was causing the
>> problem, and for each version I've tried I've uninstalled the existing
>> one 1st.
>>
>> R# is for VS2008 the only VS addin installed at the moment and I still
>> get the problem. it only seems to be affecting my XP\X64 machine and
>> not the Vista X86 or the Vista X64 machine.
>>
>> I've put all the info in the RSRP-53220 bug in Jira.
>>
>> "Serge Baltic" <baltic@intellij.net> wrote in message
>> news:dc0986bf78b1e8c9fa9e699c6768@news.intellij.net...
>>
>>> Hello,
>>>
>>>> That hasn't worked for me - I still get the find in files crashing
>>>> in this build:
>>>>
>>> Are you sure you have no conflicting R# installations on the same
>>> machine?
>>>
>>> If there's more than one R# 3.x installed (whatever VS version), they
>>> all must be of the same exactly version.
>>>
>>> -
>>> Serge Baltic
>>> JetBrains, Inc - http://www.jetbrains.com
>>> "Develop with pleasure!"
>
Hello Henning,
what version of Windows you're running on?
Thanks.
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>> Hello Mark,
>>
>> thank you, I've noticed your comment to the request. It would be nice
>> if
>> you try to attach a debugger to VS prior to opening the Find in Files
>> dialog,
>> set break on any exception, and then try to open dialog - probably
>> this
>> will help to reveal the origin of the crash. Thanks.
>> Dmitry Shaporenkov
>> JetBrains, Inc
>> http://www.jetbrains.com
>> "Develop with pleasure!"
>>> I have run the uninstaller on all R# that appear in add/remove
>>> programs including the VS2005 one, as part of the process of
>>> identifying that it was R# that was the addin that was causing the
>>> problem, and for each version I've tried I've uninstalled the
>>> existing one 1st.
>>>
>>> R# is for VS2008 the only VS addin installed at the moment and I
>>> still get the problem. it only seems to be affecting my XP\X64
>>> machine and not the Vista X86 or the Vista X64 machine.
>>>
>>> I've put all the info in the RSRP-53220 bug in Jira.
>>>
>>> "Serge Baltic" <baltic@intellij.net> wrote in message
>>> news:dc0986bf78b1e8c9fa9e699c6768@news.intellij.net...
>>>
>>>> Hello,
>>>>
>>>>> That hasn't worked for me - I still get the find in files crashing
>>>>> in this build:
>>>>>
>>>> Are you sure you have no conflicting R# installations on the same
>>>> machine?
>>>>
>>>> If there's more than one R# 3.x installed (whatever VS version),
>>>> they all must be of the same exactly version.
>>>>
>>>> -
>>>> Serge Baltic
>>>> JetBrains, Inc - http://www.jetbrains.com
>>>> "Develop with pleasure!"
Hi,
Windows 2003 R2 std, english, x64, SP2, fully patched.
R# 3.1 RC1 and R#3.1 RC2.
Kind regards,
Henning
"Dmitry Shaporenkov" <dsha@jetbrains.com> wrote in message
news:c8a8a0be28838ca03db329f28c5@news.intellij.net...
>
>
>
>
>
>
>
>> Hi Dmitry,
>>
>> we experience a similar problem with the Find dialog.
>>
>> I've hit "Debug" when Visual Studio crashed and it loaded the symbols
>> from the symbol server. But it didn't load the symbols for msenv.dll
>> for some reason, so the stacktrace is not really readable.
>>
>> Any clues why this might be?
>>
>> Kind regards,
>> Henning
>> "Dmitry Shaporenkov" <dsha@jetbrains.com> wrote in message
>> news:c8a8a0be28178c9fbf187b5af11@news.intellij.net...
>>
>>> Hello Mark,
>>>
>>> thank you, I've noticed your comment to the request. It would be nice
>>> if
>>> you try to attach a debugger to VS prior to opening the Find in Files
>>> dialog,
>>> set break on any exception, and then try to open dialog - probably
>>> this
>>> will help to reveal the origin of the crash. Thanks.
>>> Dmitry Shaporenkov
>>> JetBrains, Inc
>>> http://www.jetbrains.com
>>> "Develop with pleasure!"
>>>> I have run the uninstaller on all R# that appear in add/remove
>>>> programs including the VS2005 one, as part of the process of
>>>> identifying that it was R# that was the addin that was causing the
>>>> problem, and for each version I've tried I've uninstalled the
>>>> existing one 1st.
>>>>
>>>> R# is for VS2008 the only VS addin installed at the moment and I
>>>> still get the problem. it only seems to be affecting my XP\X64
>>>> machine and not the Vista X86 or the Vista X64 machine.
>>>>
>>>> I've put all the info in the RSRP-53220 bug in Jira.
>>>>
>>>> "Serge Baltic" <baltic@intellij.net> wrote in message
>>>> news:dc0986bf78b1e8c9fa9e699c6768@news.intellij.net...
>>>>
>>>>> Hello,
>>>>>
>>>>>> That hasn't worked for me - I still get the find in files crashing
>>>>>> in this build:
>>>>>>
>>>>> Are you sure you have no conflicting R# installations on the same
>>>>> machine?
>>>>>
>>>>> If there's more than one R# 3.x installed (whatever VS version),
>>>>> they all must be of the same exactly version.
>>>>>
>>>>> -
>>>>> Serge Baltic
>>>>> JetBrains, Inc - http://www.jetbrains.com
>>>>> "Develop with pleasure!"
>
Forgot to mention: The OS is running in VMWare Workstation 6.02 Build 59824.
Kind regards,
Henning Krause
"Henning Krause" <newsgroups_remove@this.infinitec.de> wrote in message
news:fj0vok$454$1@is.intellij.net...
>
>
>
>
>> Hello Henning,
>>
>> what version of Windows you're running on?
>>
>> Thanks.
>>
>>
>> Dmitry Shaporenkov
>> JetBrains, Inc
>> http://www.jetbrains.com
>> "Develop with pleasure!"
>>
>>
>>
>>> Hi Dmitry,
>>>
>>> we experience a similar problem with the Find dialog.
>>>
>>> I've hit "Debug" when Visual Studio crashed and it loaded the symbols
>>> from the symbol server. But it didn't load the symbols for msenv.dll
>>> for some reason, so the stacktrace is not really readable.
>>>
>>> Any clues why this might be?
>>>
>>> Kind regards,
>>> Henning
>>> "Dmitry Shaporenkov" <dsha@jetbrains.com> wrote in message
>>> news:c8a8a0be28178c9fbf187b5af11@news.intellij.net...
>>>
>>>> Hello Mark,
>>>>
>>>> thank you, I've noticed your comment to the request. It would be nice
>>>> if
>>>> you try to attach a debugger to VS prior to opening the Find in Files
>>>> dialog,
>>>> set break on any exception, and then try to open dialog - probably
>>>> this
>>>> will help to reveal the origin of the crash. Thanks.
>>>> Dmitry Shaporenkov
>>>> JetBrains, Inc
>>>> http://www.jetbrains.com
>>>> "Develop with pleasure!"
>>>>> I have run the uninstaller on all R# that appear in add/remove
>>>>> programs including the VS2005 one, as part of the process of
>>>>> identifying that it was R# that was the addin that was causing the
>>>>> problem, and for each version I've tried I've uninstalled the
>>>>> existing one 1st.
>>>>>
>>>>> R# is for VS2008 the only VS addin installed at the moment and I
>>>>> still get the problem. it only seems to be affecting my XP\X64
>>>>> machine and not the Vista X86 or the Vista X64 machine.
>>>>>
>>>>> I've put all the info in the RSRP-53220 bug in Jira.
>>>>>
>>>>> "Serge Baltic" <baltic@intellij.net> wrote in message
>>>>> news:dc0986bf78b1e8c9fa9e699c6768@news.intellij.net...
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>>> That hasn't worked for me - I still get the find in files crashing
>>>>>>> in this build:
>>>>>>>
>>>>>> Are you sure you have no conflicting R# installations on the same
>>>>>> machine?
>>>>>>
>>>>>> If there's more than one R# 3.x installed (whatever VS version),
>>>>>> they all must be of the same exactly version.
>>>>>>
>>>>>> -
>>>>>> Serge Baltic
>>>>>> JetBrains, Inc - http://www.jetbrains.com
>>>>>> "Develop with pleasure!"
>>
>>