Component Services Hanging When Connecting to Other Computers

The Component Services application under Administrative Tools allows you manage the COM+ applications on different computers on your network. This is done by adding the computer to a list--a list which is then saved for the next time you open the application.

While this means you don't need to keep adding a computer, it also causes the application to hang if a computer in the list no longer exists.

If you have a computer in Component Services that no longer exists, you can make the application usable again by following these steps:

1. Open Component Services on the affected computer
2. Drop down into the Computers directory from the Component Services node
3. Make a note of the computer names in this list (apart from My Computer)
4. Close Component Services (you may need to kill the application from Task Manager)
   
5. Get the local IP address of another computer on your network that the affected computer can access
   
6. Open the hosts file in a text editor (the file can be found in \System32\drivers\etc\
7. Add entries for each computer name you noted, assigning the IP address from Step 5
8. Save the file
9. Reopen Component Service and drop down to the computers list
10. You may have to give it a few minutes, but now you should be able to select the other computers in the list and remove them
11. Edit the hosts file again to remove the entries you've added

Follow these steps and you should be able to get Component Services back in working order again.

How to Complain

Partially inspired by Adam's Premium Rate SMS Abuse post, I thought I'd republish a post I made a few months back on a different blog about how to complain. It doesn't fit in completely with the exact situation Adam discusses, but I feel there's a couple of things that are still relevant:

We all have to complain at some point. Some people feel the need to complain more than most, but sometimes something will happen that we have every right to complain about. When that time comes it can often be frustrating even finding the person to complain to, so when you actually get to talk to someone tempers can already be frayed.

I've been working with software for a number of years now, so I've been on the receiving end of a fair few complaints. These have ranged from the perfectly calm, reasonable complaint over something that genuinely is a problem, to an angry, swearing marathon yelled down the phone at you as if you were some troublesome infant. So I thought I would be in a position to share what makes a good complaint that can be resolved quickly.

1. Make sure you actually have a problem

Just because what you have isn't doing what you want it to do, doesn't mean it is not capable of doing it. OK, you might have a problem with the usability of the product, but make sure you make that clear when you complain.

2. Make sure you can reproduce the problem

Inconsistent error reports make it very difficult to track down problems. If you can consistently cause an error by performing a set number of steps, then chances are the people trying to fix your problem will be able to as well. Reproducing the problem in a controlled environment is the first step towards resolving a problem.

3. Be clear about what is wrong

The chances are that the people looking at your problem will have a dozen or so other things to do at the same time. Their time is better served fixing problems than deciphering what problem you are having.

What were you doing before the problem? What version of the software are you using? What data had you entered in? Have you been able to perform these steps before? If yes: has anything changed with your own system since that time? Do you have a customer reference that you can give so I can look at your call history?

If you don't include answers to at least some of these questions in your initial report the people looking at your problem will just have to ask. This takes time, especially if you are difficult to get in touch with. This time could have been spent looking into why your problem was happening, if you had just provided a little more information into what problem you actually have.

4 For God's sake, just be polite!

Chances are that if you have a problem, you're not going to be too happy about it. It's stopping you working in some way, otherwise it wouldn't be a problem.

However angry or upset you are, take a few deep breaths and count to 10 before lifting up the phone and yelling at someone. You'll be more concise when you're calm--people are more likely to help you when you are calm.

Yes the person you speak to is probably being paid to help you, but that doesn't mean they have to like doing it. If you are rude and aggressive the only thing they will want to do is get you off the phone. They will tell you how you can fix the problem quickly, but this might not always solve the root cause of the problem. Yes, they are being paid to help you, but they are not your slaves/pets/children. They are still human beings with feelings that deserve to be respected.

If you're calm and polite and raise an issue, you may get that same quick fix to get you on your way, but you're also more likely to remain in memory. And who knows, maybe they'll pro actively let you know of better ways of solving the problem later. Maybe they'll even thank you for highlighting an error they'd missed.

You don't have to believe in karma to see that what goes around comes around. If you're polite to them, then they will repay that by being polite to you.

5. ...and shut up and listen to them!

This might seem obvious, but too many times people just don't listen to the help they are given. Make sure you don't fall into this category.

You might think you know what is causing the problem, and by all means offer this to them, as long as you are polite about it. But if this doesn't turn out to be the issue, then don't cling to what you think is right! Customer support does actually look into problems! They wouldn't tell you something different if it wasn't true!

Listen to them, and understand what you are told. Don't be too proud to say if you haven't understood. They should be able to tell you again using concepts you're familiar with. If you still can't understand then get them to write it down so you can forward it to someone who might.

You don't want to have to call them again with the same problem do you?

6 Understand that calls are prioritised

Your problem may be bugging you a lot, but if you are able to work around it, then your problem will be put lower in the pile of outstanding calls. No company has the man-power to answer every support call it receives immediately, and critical problems will always be investigated first.

If your problem is that you don't like that you can't change the order of some data in the application you are using, then this will fall behind a call from another company for which the application doesn't work at all.

All customers are important, and all customer support calls deserve to be answered promptly. But understand that not all calls can be solved immediately, so don't get angry and think you've been forgotten. The company that you are dealing with does value your custom and your call, but you have to understand that you are not their only customer, and occasionally other customers' calls need to be dealt with before yours.

Surefire Money Maker

Anyone who has written a non-trivial piece of software will be aware that the occasional bug is inevitable. Unit and acceptance testing, and a QA process can limit the number of bugs that can creep out into the wild, but there will always be the odd bug out there.

If a company releases a piece of software that stops customers working, it is up to that company to put it right as soon as possible.

I was talking to a friend this week who tells me that not all software companies follow this rule. He's a software developer too, and (as I understand it) most of his work is dependant on a piece of software provided by another company.

He found a bug with this piece of software that caused it to be pretty unusable, so filed a bug report, only to be told he must pay to have this bug fixed.

How about that? A company has released a defective piece of software to a paying customer, and then told that customer they must pay an additional charge to get it working properly.

Talk about a guaranteed money maker.

I suppose this is where the software's licence agreement comes in, which usually has a clause saying something like "we make no guarantee that this software will do anything you need it to, including the purpose we sold it to you for".

Potential Breaking Change For API Customers

We are currently working on reassembling multipart inbound messages before they are placed into inboxes, which has the effect of increasing the maximum length of an inbound message from 160 to a purely theoretical 38,862 characters.

Esendex customers who use the API to receive inbound messages and have restricted their systems to the current 160 maximum will need to increase their current restrictions.

Read more here.

Esendex Inbound Multipart Messaging Update

Most people who use SMS will know that a standard SMS message is limited to 160 characters (using a standard 7-bit character set). But most people will also know that mobile phones are capable of sending a message of more than this.

The phone does it by splitting the message into parts, and placing a header on each part that describes:

• how many total parts there are in the message


• which part this current segment is


• a reference so parts from different messages don't get mixed up

Esendex's outbound service has supported sending these long messages for more than a year, but at the moment we treat inbound message parts as separate messages.

We're currently working on an update that will cause these message parts to be reassembled into one message, so all parts (or however many parts we actually receive) will be displayed as 1 message in the Inbox.

So what is this going to affect? Well, if you use the website to view your inbox, or have your messages emailed to you, then this won't affect you at all--all you will see is a longer than usual message if a multipart message is sent to your account.

However, if you have written an application that retrieves your messages from your Inbox, or which receives direct messages through the Application Notification service, then this could potentially be a breaking change.

If you are expecting a message to be a maximum of 160 characters, you will need to modify your code and/or database tables to accept messages longer than this. If you need to apply a maximum length, then the limit of 1 Esendex inbound message will now be based on the total characters in the maximum number of parts allowed by the specification.

The maximum number of parts is stored in an unsigned byte starting at 1, which gives a potential for 254 parts(!). Each part can have 153 characters, which gives a technical maximum of 38,862 characters in an inbound message.

However, I seriously doubt any provider or phone manufacturer will allow anyone to send a 254 part message. I certainly know that phones have their own limits on the number of parts a handset can send.

As an example Esendex's outbound service limits you to sending 4 message parts, or a total of 612 characters.

A maximum of something like 1000 characters should probably handle most cases, but the potential is there for 10s of thousands of characters under the right circumstances.

This update is currently in development and will hopefully be going live in September sometime. I've been told an email will be sent around to API customers giving an official announcement, but you can get a head start on any changes you need to make right now.

Enable Internal System.Net Logging

Having trouble with certificates while requesting information using HttpWebRequest, manifesting itself with the error "Could not create SSL/TLS secure channel". As far as we could tell the certificate should have been ok.

To diagnose the problem I found this great blog post to enable the internal logging from the System.Net classes by Durgaprasad Gorti over at the MSDN Blogs.

Just needs a new section in the app.Config file to log out what the System.Net classes are doing. One of the samples in the blog post worked straight off for me:

<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
    <system.diagnostics>
        <trace autoflush="true" />
            <sources>
                <source name="System.Net" maxdatasize="1024">
                    <listeners>
                        <add name="MyTraceFile"/>
                    </listeners>
                </source>
              <source name="System.Net.Sockets" maxdatasize="1024">
                    <listeners>
                        <add name="MyTraceFile"/>
                    </listeners>
                </source>  
           </sources>

            <sharedListeners>
                <add
                  name="MyTraceFile"
                  type="System.Diagnostics.TextWriterTraceListener"
                  initializeData="System.Net.trace.log"
                />
            </sharedListeners>
            <switches>
                <add name="System.Net" value="Verbose" />
              <add name="System.Net.Sockets" value="Verbose" />
            </switches>
    </system.diagnostics>
</configuration>

It creates a file called System.Net.trace.log in the directory where the EXE is running. The logging is very comprehensive and will point you in the right direction for fixing your problems.

Ohh.. Polls

Maybe I'm behind the times a bit with this, but I've found you can add polls to your BlogSpot blogs. They're a page element you can add from the Template tab. I'm sure it wasn't there the last time I looked.

Blog Rethink

I grow tired of maintaining two blogs so I've decided to scrap my personal blog.

I'm keeping the blog you're reading now since it gets more traffic and has external links to it. But I've renamed it as my personal blog instead of Development Blog.

There'll be no changes in the address though, so the only thing you may notice is the odd post that isn't about software development--something that's been happening lately anyway.

Jeremy Vine Steps Up

The BBC News article Unmitigated ferocity, here I come caught my eye during my lunchtime news fix. In it Jeremy Vine talks about an incident he witnessed on the tube in which a man harassed a female passenger while the rest of the carriage looked on. As the man left, and the doors closed, another passenger flicked two fingers at him, only for the man to return and beat up the passenger when the doors happened to reopen.

This type of violence is now getting more common in most of the large towns and cities in Britain, and people lucky enough to have not experienced it first hand will probably think that they would not sit idly by and be a silent witness to it.

The reality, as Vine states, is quite different. As a nation we are relatively introverted and most people just want to get on with their day and not get involved. Plus there's the additional risks of getting the beating yourself, or being charged with assault if you happen to succeed in placating the thug.

As someone who has been on the receiving end of such violence the article struck a particular chord with me.

After a night out with friends I sat on the last bus home opposite two men (one older than the other) flanking a young woman looking very worse for wear and with no shoes on. I remember asking the older man (who was already glaring at me) if she was ok with no shoes on. For my trouble I got a stream of obscenities, but worse was to come when the bus approached my stop.

All three followed me from the bus and started kicking and punching until I managed to push past the shoeless girl and get away. Luckily they didn't pursue, as I was bleeding from my head and spent the rest of the night in Kings Mill Hospital.

Calling an ambulance for an assault led to a police report being filed for an ABH, and although I went through a number of mugshots and indicated a couple of potentials, nothing else has happened. Apparently the CCTV on the bus was not working on that night.

In hindsight I would have loved to have turned the violence back on them, but at the time all I could think was "This hurts, I need to get away", rather than "This hurts, I need to hurt them too". I suspect that this is the thought most people would have given a similar situation.

I would have liked for someone to help as Vine says he will do from now on, but I understood then as I do now the risks that someone else would be taking on my behalf. It's OK standing up to verbal abuse as he did on the bus, but wading into a fistfight is something else entirely.

I know I won't be physically fighting for a stranger any time soon, I prefer to keep my head down to avoid such confrontations in the first place. But I do admit that it is this mindset that is partially responsible for the violence we see now on almost a daily basis in the news.

Vine is right, by doing nothing we give the thugs permission to carry on as they are. But members of the public aren't the right people to be stopping such violence. Police do wade in and break up these fights when they happen late at night in the city centres, but who will stop the violence elsewhere?

TransactionScope Stumbling Block

I returned to work this morning after a week's holiday to discover that all was not well in the TransactionScope camp. A certain four letter word that I won't repeat here sprang immediately to mind.

Luckily, tests had highlighted the problem before this went live, but the setback is disappointing at best and for me it's personally infuriating as I was the person who suggested it and took the lead in its development.

I've not had chance to look in a great depth at what the team investigated during my absence, but there might be a light at the end of the tunnel. The articles Nicholas has linked to (articles 1, 2 and 3 for your convenience) certainly suggests a reason to the problems we are seeing, but they might not be the root cause of the particular problems that the tests highlighted.

I mocked up an application involving instantiating two SqlConnection objects enlisting in the same TransactionScope weeks ago, prior to even suggesting we implement the pattern fully, and saw no problems with it.

Could this problem be purely down to a long running transaction timing out?

In Nick's words: To be continued...

Problems Rotating Models in XNA

After finding Blender I've created some simple cubes and exported them into an XNA project. I want to rotate these after receiving input from the GamePad (although currently I'm testing with the Keyboard).

The idea that I have calls for the cubes to be rotated 90 degrees after a button press. The camera isn't moving, so having a cube rotate in this way means that the cube will always be displaying a full face.

I've figured out how to rotate, but as soon as I rotate around more than 1 axis I have to consider which direction the cube is facing to determine which direction I should rotate based on the next button press.

The cube needs to rotate up and down, and left and right, and the buttons to do this should be the same regardless of the cube's current orientation. My initial simple hamfisted attempt at rotating didn't take this into account. So if I rotated left and then pressed the button to rotate up, the model twists clockwise.

I rather stupidly failed to realise that the rotations are being done in relation to the model. Hindsight tells me how stupid I am for not realising this--how difficult would model movement and rotation be if everything was done in relation to the camera or an absolute point?

But now I know this it's got me wondering how I can achieve what I need. I suspect I need to store the current orientation of the cube, and then based on this determine which way is up so I can rotate accordingly.

Anyone have any experience of rotating models in this way?

XNA Arcade

Over at Ziggyware XNA News there's a post about XNA Arcade.

Kyle Schouviller's created the application to allow people to easily distribute their XNA games.

Haven't checked it out yet, and it is still in it's alpha stage, but the concept certainly sounds interesting.

Check out the application here.

Carbon emissions in Walkers Crisps

Had a pack of Walkers Crisps at lunch, and noticed on the back it says "75g of Carbon emissions calculated per pack". And this is on a standard packet of 34.5g crisps.

While I admire Walkers for their transparency when it comes to the carbon emissions I can't help but wonder what they're expecting their customers to do with the information. Am I more likely to buy a snack that has a lower "carbon footprint" than another? Well, probably not, but maybe. I suspect we like to think we buy food based on things like taste and nutritional content, but like it on not we are all swayed by things like packaging and the perceived image of the product.

So now along with checking how much fat, salt, sugar and calories are in our food, must we now check the carbon emissions too?

And if I do stop buying food that has high carbon emissions, is it going to make any difference? The food has already been manufactured by that point--any damage already done. It would take a lot of customers turning away from high carbon foods to make a manufacturer modify their process to reduce their emissions, and I doubt enough people care to make that happen.

Culture name 'az-az-latn' is not supported.

Check out the list of cultures that the .Net Framework supports, and you'll see that there is no entry for "az-az-latn", and unless you've got this culture string saved somewhere you might be wondering where it's coming from. Well, look in the text above the list on the same page and you'll come across this little gem:

On Windows Vista and later, a culture name including a script can be rendered using the pattern --. An example of this type of culture name is uz-Cyrl-UZ for Uzbek (Uzbekistan, Cyrillic). On pre-Windows Vista operating systems, a culture name including a script is rendered using the pattern --, for example, uz-UZ-Cyrl for Uzbek (Uzbekistan, Cyrillic)

So following this pattern "az-az-latn" is an example of a culture name including a script on a pre-Windows Vista operating system. As we don't run Vista on any of our machines we found it a little puzzling that this error should be being thrown: we have a pre-Vista OS using pre-Vista culture names.

Then we realised that a number of updates had recently been applied, one of which was for the .Net Framework. By the looks of it, this .Net Framework update has changed the style of culture names to be the same as the ones on Vista. Our assembly had old culture names cached, so simply restarting after the update cures the problem.

Exceptions from Threads in Threadpool

I've had a question in a comment of EventType clr20r3 From Windows Service from quantboy:

if a thread from the threadpool throws, can you prevent that exception from taking down the entire application by wrapping the code that thread runs within a try-catch block?

Simple answer from my experience is yes. The only time we've seen a thread take down an application is when it throws something out of the method that the thread is running. Simply wrapping that code in a try...catch allows the thread to stop gracefully, and if you place some logging in the catch block you'll get much more meaningful errors.

Then you should be able to work towards fixing why the method is throwing in the first place :).