Typelibbuilder crashes during javascript intellisense. - by JBBerke

Status : 

  External<br /><br />
		This item may be valid but belongs to an external system out of the direct control of this product team.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 336160 Comments
Status Closed Workarounds
Type Bug Repros 18
Opened 3/31/2008 10:31:38 AM
Access Restriction Public


I've been having issues with VS2008 Professional when building a web site. TypeLibBuilder.exe crashes routinely. This has been submitted before as a bug and you guys closed it. Recently this occurs every time I mess around with my javascript (And it is not being disabled like it used too). This is making developing a web app next to imposible. 

This occurs on a new web site. It will crash when I add the scriptmanager, or if I try and edit a property of it or click in the script block.

Please contactif you need anything. Since it occurs on a brand new project I'm guessing its an environment issue, and I am not sure what you would need. joshua.berke@gmail.com

Here's the page:

<%@ Page Language="VB" AutoEventWireup="false" CodeFile="Default.aspx.vb" Inherits="_Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>Untitled Page</title>
    <script type="text/javascript" >
    <form id="form1" runat="server">
        <asp:ScriptManager ID="ScriptManager1" runat="server">

Sign in to post a comment.
Posted by Z O T on 12/28/2009 at 7:24 AM
Got work around with some jquery plugins null error. Thanks to : Jeff King

Quote :
6. I'm getting a "childNodes is null" error, what is it and what do I do?

If you're using jQuery, the "childNodes" error is indicative of IntelliSense not happy with a particular plug-in. Note, the error will misleadingly point to the jquery-1.2.6-vsdoc.js file. The cascading set of errors lands in the core jQuery code, however it originates from the plug-in. For example, the jQuery UI DatePicker is one of the plug-ins that will show this error.

Generally for any JavaScript library, a "childNodes" error is caused by libraries that try to create DOM elements on parse rather than slightly later on load. DOM element creation is not supported at design-time (IntelliSense-time as I call it) and thus you get a null reference exception when you try to call "childNodes" on the element. Note, this is a perfectly acceptable pattern... it's our fault that it causes an error. In fact, we've made some major architectural changes to accommodate this in Visual Studio 2010 but I'll save that for another post.

We will try to work with library owners to product VSDOC files for their libraries in the future. For now, the best option is to hide the file from IntelliSense... see question #8.

7. What makes a jQuery plug-in incompatible or compatible for IntelliSense?

There's no hard and fast rule for compatibility with IntelliSense. However, from my experience, if a plug-in is going be incompatible, it's going to be because it tries to create and modify a DOM element before the document is ready. Please see the previous question for more details. If you frequently see another type of issue, please let us know (via a comment on this post or you can email me... address at the bottom) and we'll be sure to investigate to provide an explanation.

8. How do I hide a file from IntelliSense?

"Igor" came up with a clever solution outside the box of what the "vsdoc" feature was originally intended for. =) However, I think it's great and worth repeating. You simply create a empty -vsdoc.js file for the offending library... effectively making Visual Studio skip the problematic ones. Of course this means you get less IntelliSense, but it's better than none.

9. Can you add support to recognize more file extensions?

I saw a request from "Jerry" to recognize the "dash debug" convention. I also saw some folks mistakenly use a "dot vsdoc" naming scheme. Note vsdoc is supposed to be a "dash vsdoc" rather than "dot". Of course there's also the "dot min" extension for compressed files. We can definitely add support for more file extensions in a future release. Feedback for which ones are the most important would be helpful in making sure we support the right set.
Posted by Z O T on 12/28/2009 at 6:28 AM
Surfing through net for over 2 hour and still not find work around for this one. Has been over a year already and where is the solution ?????? Mine doesn't have DigitalPersona/fingerprint reader.
Posted by Andrey Sidorenko on 10/22/2009 at 3:25 AM
I don't have DigitalPersona or something like this installed and it happening on my desktop as well.
Posted by HotAir on 6/11/2009 at 7:56 AM
It is an issue on my desktop and I do not have a fingerprint reader.
Posted by katman97 on 3/11/2009 at 6:20 PM
This issue should really be opened and resolved instead of marked as closed since the issue is still happening. The workaround suggested is not a long term fix.
Posted by Cipherzero on 9/24/2008 at 8:36 AM
here is the exception i get
System.ComponentModel.Win32Exception was unhandled
Message="Error creating window handle."
     at System.Windows.Forms.NativeWindow.CreateHandle(CreateParams cp)
     at System.Windows.Forms.Timer.TimerNativeWindow.EnsureHandle()
     at System.Windows.Forms.Timer.TimerNativeWindow.StartTimer(Int32 interval)
     at System.Windows.Forms.Timer.set_Enabled(Boolean value)
     at System.Windows.Forms.Timer.Start()
     at TLBServer.TLBServer.DoError(Exception e)
     at TLBServer.TLBServer.Main(String[] args)

Posted by Korayem on 9/13/2008 at 6:31 PM
I have the same issue with Visual Studio 2008 Pro SP1 and found that the problem was related to the fingerprint software on my Vista x64 Home Premium.

I blogged about it:
Posted by JBBerke on 6/11/2008 at 10:48 AM
Can you please provide an update on the status of this? I've seen the bug go from open to close several times over the last few weeks.

Posted by JBBerke on 5/6/2008 at 5:55 PM
I attached a dump I created with windbg. When I debugged through that it looks like it ran to the stack error.

Hope this helps
Posted by JBBerke on 5/6/2008 at 5:43 PM
I can't debug past the exception. It shuts down the whole process (didn't look like the exception was being handled).

I think the issue is the debugger being attached. I wrote a real simple stub and swaped out the real TypeLibBuilder to see what the arguments coming in are. I get these arguments...


When I am not going through the debugger these are the arguments:


I have not modified any of the atlas scripts; however, the other error was due to me removing the reference to MicrosoftAjax.js (not sure when I did that)

Posted by Microsoft on 5/6/2008 at 5:02 PM
That latest dump didn't contain anything useful. Can you try running the debugged typelibbuilder past any exceptions until you get to the stack overflow?

I don't know why that other error is happening or why the state of your machine changed.

I think that Atlas defines Type as another name for Function. It almost sounds like the Atlas core is not being processed before the web forms file. I can't imagine what might be causing that.

Are you using the version of Atlas that was installed with VS 2008?
Posted by JBBerke on 5/6/2008 at 12:22 PM
Not sure if this helps, but when I was working today, I got a new error from the Atlas scripts:
Warning    1    Error updating JScript IntelliSense: MicrosoftAjaxWebForms.debug.js:: 'Type' is undefined @ 8:0    D:\Source\****\***.***.****\JS\gridHelpers.js    1    1    D:\...\****.****.****\
Grid helpers has a reference to: ///<reference name="MicrosoftAjaxWebForms.js"/>. This had been working for several weeks. Let me know what else I can provide you guys.
Posted by JBBerke on 5/5/2008 at 2:44 PM
Good, I didn't feel like learning Windbg tonight;-) I attached the latest post, and I got this error: An unhandled exception of type 'System.FormatException' occurred in mscorlib.dll

Additional information: Additional non-parsable characters are at the end of the string.

When I click continue it looks like VS still thinks typelibbuilder is running. I hope this helps let me know.
Posted by Microsoft on 5/5/2008 at 2:27 PM
Try 'vsjitdebugger.exe'. I intended to post this blog entry which gives cleaner instructions: http://blogs.msdn.com/greggm/archive/2005/02/21/377663.aspx.
Posted by JBBerke on 5/5/2008 at 2:15 PM
I'm having a hard time getting this work. I assume I should be using the debugger option and I set it to devenv.exe.

VS did open up but I got a msgbox with this message:

Microsoft Visual Studio
The following files were specified on the command line:








These files could not be found and will not be loaded.

Should I try this with windbg?
Posted by JBBerke on 5/5/2008 at 2:07 PM
Ok i will give the other directions a shot. I agree with that it must be occuring in Atlas framework, since I only have an asp:scriptmanager on the page and it occurs. Plus it sometimes occurs on a blank js file with a reference MicrosoftAjax, but not always. I just added a blank js file and the reference and it crashed then I closed and reopened the file up and it worked fine.
Posted by Microsoft on 5/5/2008 at 1:44 PM
Hi Joshua,

The dump you provided was for VisualStudio. I need the dump for typelibbuilder.exe. If you follow the directions at http://blogs.msdn.com/junfeng/archive/2004/04/28/121871.aspx you may be able to get a dump.

A call stack I saw on one of the bug reports suggests that some piece of Javascript is entering an infinitely recursive loop (we actually execute referenced scripts top generate intellisense). The CLR crashes hard when it gets a stack overflow error.

Since this is happening on a new web page, the loop must be occuring in the Atlas framework. I'm wondering if some value in one of the browser type schemas is causing this. You can change the schema using the combo box on the "HTML Source Editing" toolbar. Although, I've tried all of the possible schemas on my box and couldn't replicate it.
Posted by JBBerke on 5/5/2008 at 10:21 AM
I attached the dump, I hope this is the right one. The directions didn't match exactly. For example when the crash occurs control does not go to the second instance of VS. So I had to break the process and then do a dump. I did this while the window was open that told me typelibbuilder had crashed and was asking to me close it or debug. I also tried to debug that instance and save the dump, but when I went to debug, the save as dump was not enabled.

I'm more then willing to get into a live meeting, remote desktop etc... and let you have a look joshuaDOTberkeATgmail.com
Posted by JBBerke on 5/5/2008 at 10:03 AM
The workaround doesn't actually work. I was the one who posted that and I thought it had worked at first (I went a lot longer without crashing) but then it started occuring again.

I will post a the crash dump shortly.

Posted by Mikhail [MSFT] on 5/5/2008 at 9:38 AM

Unfortunately, Watson dump does not seem to contain useful information. Can you also obtain a crash dump using VS as described here http://blogs.msdn.com/mikhailarkhipov/archive/2006/07/25/678308.aspx (attach to typelibbuilder.exe as both managed and native), zip it and attach to the bug?

Posted by Mikhail [MSFT] on 5/5/2008 at 9:35 AM

One user found a workaround: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=322157. Does the same workaround work for you?

Posted by JBBerke on 4/1/2008 at 4:34 PM
I found a new way to cause this to crash I add a new jscript file and as I am typing: ///<reference name="MicrosoftAjax. TypeLibBuilder crashes.

Any time I open an external js file with this TypeLibBuilder crashes.
Posted by Microsoft on 3/31/2008 at 7:09 PM
Thanks for your feedback. We are escalating this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you,
Visual Studio Product Team