Loader Lock exception in windows applications

Blatantly ripped from: http://www.thezbuffer.com/articles/304.aspx

Error Message:

LoaderLock was detected
Message: DLL '.......\Microsoft.DirectX.Direct3D.dll' is attempting
managed execution inside OS Loader lock. Do not attempt to run
managed code inside a DllMain or image initialization function since
doing so can cause the application to hang.A Loader lock is one of the Managed Debugging Assistants (MDAs) that were added to VS2005 to help find hard to debug runtime issues. There is code in all Managed DirectX 1.1 assemblies that causes this MDA to fire. Microsoft have confirmed they are aware of the problem. However I do not expect to see a fix for MDX 1.1 since current efforts are focused on MDX2.0/XNA Framework, it ONLY affects code run under the debugger (i.e. it won't happen when users run your EXE) and there is a trivial workaround. I'm not sure of exact reproduction steps - it appears to fire on some projects and not on others.

To work around the problem you have several choices:

Go back to using VS2003 and .Net 1.1
Use MDX 2.0. Note that MDX 2.0 will never actually ship as it is being transformed into the XNA framework.
Disable the loader lock MDA. Debug/Exceptions (ctrl-D, E), Open the Managed Debugging Assistants tree node and uncheck Loader Lock. This setting is per solution so it will only affect this solution.
Versions affected:All .Net 1.1 Managed DirectX assemblies when used with Visual Studio 2005 and .Net 2.0.

My apologies, but I will get around to writing my own piece on this particular exception and it's foibles myself when I've got time!

Top 10 Worst Album Covers Of All Time

Yeah, I know, it's a complete waste of an entry, I just wanted to try out the new blogger engine and thangs, y'all know.

Check out http://salamitsunami.com/archives/91 for some laughs, old though I know it is. Maybe I can generate some hits, but then again, people might start reading this drivel.

Onk.

The Bluetooth Saviour

I discovered a very useful little help page somewhere long ago, then lost it again. It was to do with installing WIDCOMM drivers for the USB BT dongle (mine's an ePox dongle.) Anyway, I found essentially the same document written by someone over at:

http://www.geekzone.co.nz/forums.asp?ForumId=8&TopicId=2200

I thought I would repost it here, as long as they don't mind, and hopefully it will stay available for all perpetuity...


This is a small guide for those who installed the Service Pack 2 for Windows XP and are experiencing problems with the WIDCOMM Bluetooth software..If you install the WIDCOMM BTW 1.4.2.10 Bluetooth software on Windows XP SP2, you will get the following error as soon as you double click on the blue-red system tray icon:"Your Bluetooth Software license does not include use with this Bluetooth Device"After that you will be asked to point to a valid license.dat file. However if you select the license.dat that came with your manufacturer's driver (be it on CD-ROM or downloaded from the manufacturer's website) it still won't work.The reason for this problem:In the Service Pack 2, Microsoft included a generic Bluetooth driver, naturally being WHQL-certified -- it's directly from Microsoft. The WIDCOMM Bluetooth driver however is not WHQL-certified, so Windows XP continues using the generic driver. This interferes with the WIDCOMM Bluetooth software resulting in the above error.To force Windows XP to use the WIDCOMM driver, perform the following steps:Don't plug in the Bluetooth device yet.If you have any Bluetooth software apart from the included Windows drivers installed, deinstall them and reboot. I am not sure if this is necessary, but just in case.Install the WIDCOMM BTW 1.4.2.10 Bluetooth software. When it asks you to plug in the Bluetooth device and click OK, don't, and click cancel instead.When the WIDCOMM setup has finished, plug in your Bluetooth device and let Windows install the driver. (There should be two Bluetooth icons in the system tray; one blue-white: this is the Windows driver - and one blue-red: this is the WIDCOMM driver which is deactivated.)Now go to the Device Manager, right click on the "Generic Bluetooth Radio" and select "updatedriver". Don't let Windows XP connect to the internet, then select "Choose software from a list or specified location". In the next window, select "Don't search, but select the driver to install".In the next window, activate "Show compatible hardware" (if it isn't activated already) and select your manufacturer's driver instead of the "Generic Bluetooth Radio" driver.Click next until the new driver is installed. Now the WIDCOMM system tray icon should be blue-white as well, activated and ready to use.If you now double click on "My Bluetooth Places" (e.g. on the desktop), the WIDCOMM software installation will be continued and finished.This should solve any compatibility issues with the WIDCOMM BTW 1.4.2.10 Bluetooth software and Microsoft Windows XP SP2.If you still experience problems, please reply to this thread. If necessary, I will update this HowTo accordingly.

Net Tears and Code, Sniff

Ok, so I've been right gettin inta CodeSmith and NetTiers this past few months and it's all wicked.

Seriously useful shit.

I'll post back here more when I can figure out exactly how to post code without having to trick the parser in the blogger.

DataList ItemIndex and GridView DataItemIndex

I've been messing with things in .NET2 and found the following...

Inside a DataList you can do this:

< % # Container.ItemIndex % >

Which databinds the current item's index to whatever so it can affect the rendered output
(why else would you do it, d'oh!)

But in GridView you have to do this:

< % # Container.DataItemIndex % >

For example, I have a datalist in which I want to have a thick border around only the first item (an image and some text) in order to make it obvious that that is the main image in the gallery

I use:

< border =" '" itemindex ="="">
' >

But in a grid view, where i want a label in the first column of only the first row, I use:

< runat="server" id="Label1" text="Main" visible="'" dataitemindex ="=""> '
/ >

This time it's technical

Ok, long time no post. Here's one for .NET developers having issues with the old

"Microsoft.Practices.EnterpriseLibrary.Data.Instrumentation.DataConnectionFailedEvent"

and occassional

"System.Security.SecurityException: Requested registry access is not allowed."

We changed server in the end. I did find a solution on a blog page somewhere, but I can’t find it now – here’s what I wrote in an email to a colleague:

1. Go to: “C:\Documents and Settings\All Users\Start Menu\Programs\Microsoft patterns & practices\Enterprise Library\Quickstart Applications\Logging & Instrumentation Application Block” or (if you downloaded Enterprise Library circa June 2005): "C:\Documents and Settings\All Users\Start Menu\Programs\Microsoft patterns & practices\Enterprise Library - January 2006\QuickStart Applications\Logging Application Block"
2. Load: “CS Logging QuickStart”
3. In ‘Solution Explorer’ highlight ‘Common’ (this should be the top project)
4. Open the drop-down menu over the ‘Common’ project
5. Select ‘Properties’
6. In the left-hand menu select ‘Configuration Properties’
7. In the left-hand menu select ‘Build’
8. In the right-hand pane, change the value for ‘Conditional Compilation Constants’ to: DEBUG;TRACE
9. Click OK
10. Change the build mode to Release
11. Rebuild the entire solution
12. Copy the Common, Configuration and Logging DLL's from the "C:\Program Files\Microsoft Enterprise Library\QuickStarts\Logging\CS\LoggingQuickStart\bin\Release" (if you downloaded Enterprise Library circa June 2005): "C:\Program Files\Microsoft Enterprise Library June 2005\src\Logging\bin\Release" into your own project (as you did way before you started getting all these errores)
13. Rebuild your own project.

Rebuild and it should work; you’re basically changing the build options of the project so as not to use the logging mechanism (ie: leaving out the part which is throwing the error). This is safe (for me, at least) because I never look at the logged output in the system logging application anyway; if I want logged information I use my own log (or stop points).

I think the default MS .NET logging is a good idea, but in practice it falls down because not enough developers get so deep into manipulating the system’s properties and functions to make it worthwhile figuring out a solution than writing their own. The logging is exactly this, good in principle, but requires lots of permissions which are, stupidly, not assigned by default to the .NET system user (if you’ve had problems writing files to supposedly permitted directories you’ll understand what I mean).

Ok, so I've decided to start recording my discoveries and successes in C# land here because otherwise I'll never have anything interesting to write. And I'll simply lose all my own solutions if I don't.