If a picture is better than 1000 words, what about a 3 minutes video?
Lot of new stuff is coming for web developers: take a look, smile and download
And here is a post about what's new in IIS7 on this release.
As Mike, I'm also interested in the psychological and unconscious side if human beings... and after reading this post I took the personality test based on the Myers-Briggs personality tests.
Well, it turns out that I'm an INTJ (and here) . Preferred careers are in computer programming, engineering or natural science... very close! And also I recognize myself in the personality descriptions they gave... nice
Anyone willing to take the test and share the result?
Hosting a Windows Control Library control in an ASP.NET 2.0 page, the WCL does not resize correctly, if you change the size of the IE Window. The problem does not occur using .NET Framework 1.1
The problem is a regression in Visual Studio 2005 which prevents the .Net ActiveX implementation from asserting managed code privilege when calling IOleClientSite::OnPosRectChange. Since that call requires managed code execution privileges, it fails and the control cannot resize itself.
The workaround is to set the size of the control from the HTML rather than resizing it internally. For example, the onresize in the body tag in the following script does this:
<OBJECT id="obj1" height="90%" width="90%" classid="MyResizeControl.dll#MyResizeControl.UserControl1" VIEWASTEXT />
<br> This is a long string for me to test the other space
Capitalization of the properties is important: capital "W" (Width) will correctly change the Width property of the internal .Net control; lowercase "w" (width) will change the property of the HTML object rather than the .Net object, and this will not work if the .Net object is 1.1.
My colleague Stefano had this case a few weeks ago, but since he has not a blog (yet ) and I've been partially involved in it, I thought this might be interesting to share...
The source code of the page looked like this:
<input type=text id=text1 onblur='logWriteLine("text1.onblur called");button1.disabled=true;'/>
<button id="button1" onclick='logWriteLine("button1.onclick called");'>button1</button>
I tested this on all of my 3 machines in office and always worked just fine, while Stefano was able to reproduce the problem reported on his machines... Here is what he did:
Note that the repro is not always consistent (depending on the machine), and it never repros with Firefox.
Given an appropriate machine it systematically reproduce, but on that same machine this never happens with Firefox.
After some testing and log analysis on customer's machine, It turned out that they were facing a kind of race condition. This explains that it is working on some machines but not on all even with the same binaries. Firefox is using a complete different script engine and complete different implementation of Event handling. In IE we do not have a special prioritization of the events; this means that disabling a button while an onClick event of the button is running or will be executed next, might end in a non predictable situation. If the input field has the focus and we click the button, two events are fired: in the onBlur event we disable the object which has the onClick event, which has also been fired. I'm not completely sure, but I don't think there is an official rule how the browser should behave.
Now let's consider the following page:
// in case validation is not ok disable the button
button1.disabled = true;
<input type="text" id="text1" onclick="ButtonHasFocus=false" onblur='TextOnBlur()'/>
<button id="button1" onmouseover="ButtonHasFocus=true" onmouseout="ButtonHasFocus=false" onclick='Button1OnClick()'>button1</button>
Here we disable the button on its onClick event itself, while in the onBlur event we first check if the button is enabled or not, before disabling it. The only difference is that the onClick event gets fired anyway so you have to check here if the validation is ok before doing anything else. If it is not, disable the button. Here is what appears in our "trace" on the page:
text1.onblur calledButton1OnClick called
text1.onblur calledButton1OnClick called
Notice the difference? Now both events are fired (and logged), while in customer's sample only the onBlur event was fired and logged . We reported this to the IE team, but I'm not sure if (and when) this behavior will be changed.
Hope you don't find yourself in this tricky situation.
I'm really not a marketing guy and don't like that much the kind of shiny advertisements which makes everything looking like the best bargain ever, but I think this time it work making an exception to the rule
So, here is a bit of advertising:
But if you are like me a prefer to put your hands on things and judge with your head, then take a look at the Visual Studio Code Name "Orcas" Download page, download, install and start playing with it
This is an easy one, but we got cases like this every now and then... maybe worth repeating.
If you use Windows Integrated Authentication in IIS, everything works fine if you browse "http://netbiosname", but Integrated Authentication fails is you browse "http://dnsname". Why?
Because if the DNS machine name contains a dot ("."), the web site automatically belongs to the "Internet" zone, and by default IE does not sent the account credentials.
How to solve this? Easy, you have two options:
Update: By the way, I forgot to mention that this is also true if you use the IP address instead of the netbios name: e.g. http://xxx.xxx.xxx.xxx
Now I understand why I have troubles viewing the electronic MSDN Magazine, have a look at this post from Chris Crowe...
But I have to say that usually when I'm in that condition, expanding the content tree on the left and clicking on another topic solves the problem, at least on my machine... never mind, unlocking the file is just 3 seconds and fixes the problem forever
Just a quick and easy one for this Friday evening: let's say you have multiple w3wp.exe instances running on your web server (maybe you have multiple application pools, or you enabled Web Garden etc...), one of the ASP.NET applications you have on that server has some problems and you need to capture a memory dump to troubleshoot it: what can you do?
Easy one: install the Debugging Tools for Windows and run adplus with something like the following:
cscript adplus.vbs -hang -pn w3wp.exe
cscript adplus.vbs -hang -pn w3wp.exe
But, hey, you don't want to end up with a full dump for every w3wp.exe loaded in memory, you just need one of them, the one which is hosting your application...
Well... here is where iisapp.vbs comes to the rescue! You can find it under C:\Windows\System32 folder on your Windows 2003 machine, and if you simply run it at the command line, it'll print to the console the PID of all w3wp.exe processes running and the Application Pool ID that particular process is hosting; here is a screenshot I just took in my machine:
Since you are supposed to know under which application pool your application is running (and if you don't know you can check it through the IIS Management Console) you are ready to go! Let's say I want to dump an application running under "Live" App Pool:
cscript adplus.vbs -hang -p 4612
cscript adplus.vbs -hang -p 4612
Here we go; not comes the tricky (and funny) part: analyze the dump
... it might be that you opened a project/solution from a network share which is no longer available, or that is slow to refresh etc... I had this problem myself with Visual Studio .NET 2003 (not Visual Studio 2005 so far, so I'm not sure if this is also affected or not), and took a while to figure out what the problem was.
Procmon and some patience to go through the log pointed me to an interesting registry key: HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\ProjectMRUList (the same key exists for VS 2005, but it's under *VisualStudio\8.0\ProjectMRUList). This key contains the path of the last 20 solutions I opened/created; what's interesting is that by default Visual Studio does not show all the recent solutions opened (in File menu or in the Start Page) but just the last 6 (I usually change this value to 10), but despite that it reads all the values and (I guess) verify if the solution is still available, thus the delay...
To solve my problem I simply deleted the values pointing to a solution from a network share et voilà, Visual Studio was loading at the usual (reasonable) speed.
As you can imagine, being able to reproduce a problem on a machine you can put your hands on is the best thing to troubleshoot and resolve it, so as I guess almost all my colleagues in CSS I quite often install on one of my machines the test apps I got from customers, or make experiments to confirm/deny a theory I have... this is how this story begun.
A while ago, on my Vista x64 machine notepad.exe started to intermittently fail to load and the only "visible" symptom (of course apart the fact that Notepad was not showing up) was a very quick command prompt but unfortunately the content was impossible to read, and I had nothing in the Event Log or any other "obvious" logs. I noticed this problem because the CRM tool we use to track our work on support cases, offer the possibility to review the entire log of a call in notepad, and every now and then I happen to use that function if I want to have a quick recap of what has been done so far, specially if I got the case from another Engineer and I'm not fully aware of all the details.
As I said in my previous post I am a keyboard shortcut addict, and I like to experiment cool tools and utilities which can speed up and make easier the time I spend on a computer (which is a notable amount of hours, as you can guess ), and one of them is Slick Run (here and here a couple of posts on it from other MS guys) which I use as a replacement of the Windows "Run" command. Well, I noted that trying to launch notepad from there I got the same behavior described above, but running it from the "Run" window worked just fine... I also noted that also running C:\Windows\System32\notepad.exe (x64 version) from the file system never got a problem, while running C:\Windows\SysWow64\notepad.exe (x86 version) always failed with the same symptoms. I first thought to use adplus to look at the exception, but notepad.exe was not even showing up in the task list ; anyway, that was not yet enough annoying to worth invest some time to fix it.
Then a couple of days ago I got completely annoyed by that problem, so I decided to tackle it once for all . This time I choose a different approach, so since I was not able to easily attach the debugger to notepad I tried a different path and go directly from within WinDbg (File->Open Executable or CTRL+E) and spawn Slick Run from there, but flagging the checkbox to debug also child processes (Process Explorer shows that Slick Run is always the parent of the processes he launches)
Going forward step by step (g-> Enter to unlock Slick Run, then spawn notepad.exe, then again g->Enter to unlock notepad etc...) showed the command prompt I first was not able to read, here it is:
Ah... what is that? There is clearly a typo in that command line...! And, by the way, where does it come from?
Ok, that smelt of some debugging test I forgot to remove and it sounds it can come from the Windows Registry. Let's have a look, just search for that "adlus.vbs" and... there it is!
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe] "Debugger"="cscript adlus.vbs -crash -pn notepad.exe"
Need other clues? No, that's enough for me, thanks .
I guess this is something left from one of those debugging experiments I run on my machine (honestly I can't remember, but since I'm the only one with access to that machine, I must be the culprit here) and for some reason I then forgot to clean up... That registry comes from gflags.exe (also here), like the following
I deleted the registry key and Notepad.exe was back at work also from the CRM tool and Slick Run
I'm not sure if that is the best troubleshooting approach (probably it's not), I should have thought to gflags from the beginning but, hey, what's important is the result, isn't it? . I then found why running notepad.exe from Slick Run failed, while it worked fine from Windows Run: Slick Run is a 32 bit process and the Notepad he was trying to execute was the one from the SysWow folder (the one which failed also if executed manually from the file system), executed the one from System32 (64 bit despite the folder name).
Lessons learnt from this experience:
I started to use this tool almost 6 years ago, in my previous life before Microsoft because it was quite widely used in my former Company; at the beginning I didn't like it very much, I was used to Windows Explorer and at that time the Salamander's capabilities where not as refined as they are in the current version. But since I'm quite curious I decided to for with it for a while as an experiment, and guess what? I've never returned back from that experiment and to Windows Explorer . As the time and releases went by, new features where added (and still more are being developed), the user interface refined and performance and reliability improved...
So, what I like most of this tool? Well, quite a few things, actually...
The current version is marked as "2.5 CR2"but I've been using it for quite a while now and it has proved to be very stable and fully functional (never had a crash or other problems so far ). Now it's time to check yourself : Servant Salamander main page and download.
Update (08/05/2007):The tool has been renamed to Altap Salamander, and version 2.5 RTM is ready for download