I recently applied a firmware update to my iPhone and it broke. The phone wasn’t jailbroken and there was nothing shady about the dealing whatsoever. However, when I applied the 2.2.1 firmware, iTunes announced failure and my phone went into the revovery mode where it just shows the screen below.

iPhone Recovery Mode

I let iTunes attempt to recover my phone to no avail. I finally did some frantic Googling and came across a site called TheBigBoss.org, where I found a post about DFU Mode. I did what The Big Boss said and used the very strange shift+click* on the restore button in iTunes to allow me to choose what backup file went to my iPhone and finally was able to recover my phone.

* Note: Also from The Big Boss, “If you need to restore a specific version of firmware onto your device, rather than click restore, hold shift (PC) or option (MAC) and click restore. This will bring up a browse box where you can select the firmware you wish to program.”

I can’t believe that this had to be such a convoluted process, but I’m thankful to TheBigBoss.org website for all of the wealth of information it contained. Maybe if this blog can help one person deal with this problem just a little quicker than they would have otherwise, it is all worth it.

So, I am making a serious go of learning Rails. I have installed it on my Vista machine before, but never really given it a go. So, now that I’ve got a Mac, I decided to try to learn Rails on it. I downloaded the Ruby One-Click Installer and installed it. Per its suggestion, I ran

sudo gem install rails

Then, I got this error

Bulk updating Gem source index for:
http://gems.rubyforge.org ERROR:
While executing gem ... (Gem::GemNotFoundException)
Could not find rails (> 0) in any repository

I did some Googling and found out that I had to just run this code

sudo gem update

and select the correct packages to include. Then, I just reran

sudo gem install rails

and I was money in the bank.

I hope this helps anyone else who encounters the same issue. Now, on to working through some tutorials.

I was modifying a service last night and I got this error when I hit one of the two endpoints of the service.
The server was unable to process the request due to an internal error...
For search engines (and anyone having a hard time reading the image), it says:

The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs

The other endpoint on my service was unaffected. Usually when I do something stupid, I get the “Yellow Screen of Death” the first time I try to reach my service due to an improper web.config or some other easily correctable thing. This was the first time that I had seen this.

I did some Googling and found out specifically how to get the “real” error message. I had to change my serviceDebug tag in my service’s web.config (located in system.ServiceModel/behaviors)

 
        
          
          
        

This gave me a much more helpful message telling me that one of the elements in one of my request objects had already been defined (name and type were the defining factors) in another existing request.

There were two fixes for this. Once was a “hack” in my opinion and the other was the “correct” solution. The hack was to turn off metadata exchange on that endpoint (my particular error was related to generating the WSDL). To do that, I would have set the


to


and remove this line from beside my endpoint definition.


That would prevent developers from inside the company from generating proxy classes automatically with svcutil.exe. I didn’t want that at all.

What I did instead was to rename the element to something that made more sense anyway. This time when I built, the endpoint came up with no problem and the link to the WSDL returned the proper XML that developers would need to “reproxy”. Problem solved and lesson of the includeExceptionDetailInFaults learned!