VS2008 released

Now that VS2008 is officially released: is the most recent EAP build
compatible with VS2008 RTM?

24 comments
Comment actions Permalink

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>


0
Comment actions Permalink

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...

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>


0
Comment actions Permalink


"Thomas Freudenberg" <info@thomasfreudenberg.com> schrieb

You're soooo slow ;)

>

Just kidding, take your time. Though I bet everyone's eagerly awaiting it
:-P#


For me it works. Using it with Beta 2, RC and RTM.

Regards

Albert

0
Comment actions Permalink

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>


0
Comment actions Permalink

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 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.



0
Comment actions Permalink

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!”


0
Comment actions Permalink

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...
>

"Thomas Freudenberg" <info@thomasfreudenberg.com> schrieb

>
>> You're soooo slow ;)
>>
>> Just kidding, take your time. Though I bet everyone's eagerly awaiting it
>> :-P#
>

For me it works. Using it with Beta 2, RC and RTM.

>

Regards

>

Albert


0
Comment actions Permalink


"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

0
Comment actions Permalink

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...
>

"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


0
Comment actions Permalink

"Thomas Freudenberg" <info@thomasfreudenberg.com> schrieb im Newsbeitrag
news:fi2d4k$4ud$1@is.intellij.net...

Thanks, Albert. However, it crashes even if I close it via File -> Exit :(


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

0
Comment actions Permalink

Hello,

I tried both builds 561 and 563, and VS2K8 crashes each time I close
it. Bummer :(


What are the stack traces of the crash?


Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


0
Comment actions Permalink

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!"

>



0
Comment actions Permalink

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!"


0
Comment actions Permalink

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()

msvcr90.dll!free(void * pBlock=0x17e8b64f) Line 110 C

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...

Hello,

>
>> I tried both builds 561 and 563, and VS2K8 crashes each time I close
>> it. Bummer :(
>

What are the stack traces of the crash?

>


Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”

>


0
Comment actions Permalink

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!”


0
Comment actions Permalink

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,

>

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!”

>

0
Comment actions Permalink

Hello,

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.


Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


0
Comment actions Permalink

Ok, here you go:

ntdll.dll!_DbgBreakPoint@0()

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...

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!”

>


0
Comment actions Permalink

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...

Ok, here you go:

>
>> ntdll.dll!_DbgBreakPoint@0()

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...

>> 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!”
>>
>>


0
Comment actions Permalink

Hello,

Finally I was able to track down this issue.


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!”


0
Comment actions Permalink

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!"
>


0
Comment actions Permalink

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!"


0
Comment actions Permalink

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...

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!"
>


0
Comment actions Permalink

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...

Hi,

>

Windows 2003 R2 std, english, x64, SP2, fully patched.

>

R

  1. 3.1 RC1 and R#3.1 RC2.

>

Kind regards,
Henning

>

"Dmitry Shaporenkov" <dsha@jetbrains.com> wrote in message
news:c8a8a0be28838ca03db329f28c5@news.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!"
>>
>>


0

Please sign in to leave a comment.