GDB online Debugger | Compiler – Code, Compile, Run, Debug online C, C++

A colleague brought my attention to this awesome site: From here you can freely test and even debug your code snippets in C/C++, C++14 and even also other languages like PHP, Java and js.

A must-have link in your bookmarks. It worth a look, give it a try.


Workstation re-join to domain

microsoft_p73_05967_windows_server_2012_r2_1025605Sometimes… it happens.

You have a joyful domain with some workstations in it, and suddenly a workstation decides (or the PDC decides for that) that it would be great to exit the domain. And just to be sure you won’t understand what happened, when a legitimate user wants to logon it obtain such a message from the login attempt:

The trust relationship between this workstation and the primary domain failed.

There are many causes (human in front of all) for a workstation to leave a domain. But behind prevention of this problem, how can we solve it once it happened?

It happened yesterday to a Client of mine and I was asked to solve the problem. I had to Google around a little bit, but looking for the above message let me found some information about the problem itself and some workaround. All of those requires you to access your workstation with a local administrative account, but what if that workstation has been installed years ago, not by you, and nobody knows who is the local administrator and/or the password (even the person that is supposed to have installed that workstation)?

Well I found this workaround that at least let me enter the workstation, make the appropriate adjustment and then solve the problem. I can’t assure this will work again or it will work for you, but it worths to try.

  1. disconnect network cable (or turn off WiFi). This is to ensure that the workstation won’t reach the PDC when requesting logon
  2. perform logon normally with the user account. You might ask how is it possible, as the network connection has been cut out in the previous step. This can be done because Windows locally caches credentials in the event the PDC is not reachable…
  3. reconnect network cable
  4. open Computer Management. You will be asked for an Administrator account to use; as we don’t know who is the local administrator on the workstation, enter domain Administrator credentials (and cross your fingers)
  5. If Computer Management appears, switch to the Local User and Groups definitions. If Computer Management does not appears… you have finished to follow this guide. You’d better search a different approach.
  6. Normally the local Administrator account is disabled, but at least one local user should belong to Administrators group
  7. Select that user and reset its password. As you didn’t remember the password before, you might want to take note of the new password somewere, in the event you’ll have to use it…
  8. Pressing WIN+PAUSE will bring you to the System Status. Here you have to select the Advanced Properties, and you’ll be asked for an administrative account again. You can use once again the domain administrator credentials.
  9. Select the Network Identification tab. You will see the PC is currently joined to the domain, even though this is not working. You have to select to join a Workgroup, then give it a name (for instance TEMPGROUP).
  10. You’ll be asked for credentials of a user which can unjoin workstation from domain. Once again you’ll have to enter domain administrator credentials. You’ll be warned also that a local (administrative) account must be enabled on the workstation. We ensured it on step 7
  11. Once did, we have to restart the PC
  12. Upon PC restarting you can access it with the local administrative account given in step 7
  13. Then you will press WIN+PAUSE once again, select Advanced Properties, navigate to Network Identification tab and select to join a domain
  14. Enter the domain name, then you’ll be asked for domain administrator’s credentials
  15. Enter them, and your workstation will re-join to the domain
  16. Reboot the PC and then logon as the workstation’s normal user

That’s it.

It worked for me to rejoin a Windows 7 Pro workstation to a Windows Server 2012 R2 domain. I think that it could be used with different Client and Server O.S.. Let me know!


News from “The Lab” – New server booting!

And finally my server is up, even though not running yet.

Even after trying to fix the backplane joints that seemed to be broken, it didn’t came up as I wanted it to do.

So I firstly purchased on eBay a replacement backplane, and tried it with no luck.

Then I finally got a replacement PERC 5i card, and I solved my problem with not recognized devices.

I only have to install ESXi and start playing now…

News from “The Lab” – New server faulty?

Today I think I found out what was blocking my new server from properly booting.

This is a close-up of SAS backplane.

It’s quite hard to see, but some pins of the main Cypress component are bent. A close look with a (cheap) PCB inspection microscope made me quite sure that this damage could prevent the PERC card to properly detect the backplane itself and, in turn, the disks.

I asked my colleague to fix the problem by reworking the joints, and tomorrow I’ll test if this patch works.

In the meanwhile I’m watching some spare parts on eBay… Murphy is always watching you…

Stay tuned!

News from “The Lab” – New server troubles…

As I recently discovered, my new server is not working as it should.

After some suggestions from my friends, I tried reseating all of the internal cards, starting from the PERC 5i controller and PCIe riser card. None of them made the server to properly boot.

As a last resource I removed the PERC card (the riser card cannot be removed because it’s used to connect the front panel, with power on switch, to the baseboard). Obviously as expected the F/W initializing , along with PERC BIOS messages, didn’t came up. Connecting only the card, removing connections with the SAS backplane, brought me to the conclusion that the problem could reside into the backplane or the disks. If I remove the disks I’m warned about their absence, but reinserting them doesn’t make any blinking LED to came up.

So I suspect that I have to look after some new disks to check and then pray that the problem is not due to a faulty backplane…

More coming…

News from “The Lab” – The new server

I decded to switch over to a new server, as the old HP Proliant was unable to handle 64bit virtual machines (due to lack of BEST in its processors).

I found a cheap Dell PowerEdge 2950 with two quad-core processors, 8GB RAM and two 146GB SAS disks.


When I turned on the server after its installation, this message came up:

It seems that the PERC controller is not working… I just tried reseating it and the riser card, but no luck.

I will try to remove the controller to see if the message still persists, just to isolate the problem source.

If anyone has some ideas on how to troubleshoot this problem, please let me know.

… and it’s finally here

I was waiting my new gadget, and it’s finally here.

A couple of Onion Omega 2 plus board, a couple of prototyping expansion board and a power dock. I also have a Onion Omega (the previous version) with a couple of power dock, so I can power up all the three boards at the same time.

Now it’s time to think about what to do… Ideas are welcome!

Create and test a bootable USB pen drive

A couple of usefull links to remember, with instruction about to create a bootable USB pen drive with Windows 10 (or any other O.S.) and a way to test it without having to reboot your PC:

Waiting for my new gadget…

About a year ago I received my Onion Omega board, and it’still here on my shelf, waiting for something cool to do.

But then Onion released Omega2, a more powerful device, which doubles RAM and ROM available at a little cost. So I backed the project on Kickstarter, and my new Omega2 is on track now. I’m waiting it to be here in a couple of weeks, and in the meantime I’ll think about something to do with this new board and with the old one. I have some expansion boards (relays, OLED, Ethernet) that will be divided between the two boards to build some IoT projects.

Stay tuned!

Forcibly shutting down a Virtual Machine under ESXi

Even though this could be a last-used-resource, sometimes you need to shut down a unresponsive virtual machine in your ESXi server.

To do so the only way is to connect to the console via SSH (that should have been enabled from ESXi configuration). Then follow these steps:

  • Identify the machine you need to shut down. This is achieved running the following command and looking for the World ID of the machine you need to stop:
esxcli vm process list
  • issue the first kind of shut down option, that is a “try to shut down gracefully” command:
esxcli vm process kill --type=soft --world-id=xxxxx
  • if this not helps, try to improve your order in this way, performing a “shut down and don’t care”:
esxcli vm process kill --type=hard --world-id=xxxxx
  • if also this command doesn’t work… try this last resource, the “I told you to shut down and you do this now”:
esxcli vm process kill --type=force --world-id=xxxxx

Then you can perform all of the operation you need, for instance delete a stuck or corrupt machine from datastore.

If also the force mode doesn’t work, you’ll have to restart your ESXi server. But usually the force option is good enough to make all stucked host to turn off.