Just thought I'd post here since I've found no other hits:
I've used Virtualbox (on Windows) for years and copying and pasting (of text, anyway) always seems to have gone through phases of working consistently well or not working at all.
Anyway, I'm now running a Windows 7 VM on a Windows 10 host and 've noticed that the thing that breaks copy and paste appears to be using Excel on the guest machine.
After breaking it, killing and restarting vboxtray appears to work for about one copy and paste (but maybe only in the host->guest direction).
Rebooting (just) the guest doesn't seem to fix it - I think I need to reboot the host as well (which I tend to do infrequently).
I'm still running with the obvious solution at the moment: avoid using Excel on the guest.
Tuesday, 19 March 2019
Thursday, 8 February 2018
I was going to post this on a Samsung(USA) site where I found a thread, but it was so bloody awkward to create an account / sign in that I couldn't be bothered to complete the process.
Anyway
Anyway
(SOLVED for me - posting just in case it helps)
I've been having the wi-fi "internet not available" issue for a solid week now on my UK Samsung Galaxy S7. Won't stay "connected" for more than a few minutes usage. All other devices seem fine.
The problem appears fixed (or at least the phone has remained happily working for several hours) after I:
Firstly: Went into settings -> apps -> (...) -> show system apps -> Bluetooth Share and first force stopped, then cleared data. (I found this suggested as a solution elsewhere. It did not appear to fix it for me - but I can't rule out the fact that it's involved.)
Secondly: Went to my wi-fi router's config and DHCP-reserved an IP address for the S7's MAC. I was careful to pick a *different* IP address from the one the phone was currently using. Rebooted router (which was required to apply the reservation), turned off the phone's wi-fi (I was actually connected via a different access point, not directly to the router), turned the wi-fi back on once the router was available.
I confirmed that the phone had picked up the new, different IP. No problems since!
Cheers.
Tuesday, 23 May 2017
It's always your ADFS certificates!
Despite the fact that the error message in the event logs for your Microsoft Dynamics CRM 2013 on-premise installation say...
28005
Cannot execute as the database principal because the principal "dbo" does not exist, this type of principal cannot be impersonated, or you do not have permission.
...you'll find when you finally enable tracing with the crmdiagtool that the error in the CRM logs instead says....
System.IdentityModel.Tokens.SecurityTokenException: ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer.
The solution (and you're even more annoyed because you've tried all the bits of it except clicking through the claims-based wizard in the CRM Deployment Manager:
Update the federated metadata on the two relying party trusts in ADFS manager;
Click through the claims-based authentication wizard AND the IFD wizard in CRM;
Restart ADFS Service;
Restart IIS;
(Try all 4 again if it still doesn't' work...)
and now you're all good!
28005
Cannot execute as the database principal because the principal "dbo" does not exist, this type of principal cannot be impersonated, or you do not have permission.
...you'll find when you finally enable tracing with the crmdiagtool that the error in the CRM logs instead says....
System.IdentityModel.Tokens.SecurityTokenException: ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer.
The solution (and you're even more annoyed because you've tried all the bits of it except clicking through the claims-based wizard in the CRM Deployment Manager:
Update the federated metadata on the two relying party trusts in ADFS manager;
Click through the claims-based authentication wizard AND the IFD wizard in CRM;
Restart ADFS Service;
Restart IIS;
(Try all 4 again if it still doesn't' work...)
and now you're all good!
Monday, 27 February 2017
Yamaha Clavinova CVP-8 power supply fault fixed!
My (previously parents') Yamaha Clavinova CVP-8 must be 25 years old now. It had been getting into the habit of cutting out after it'd been on a while: all the lights would go off and the buttons would be unresponsive, there'd be no sound from the keys but a gentle background buzz from the speakers.
If you turned it off and on again immediately then you'd get a gentle pop and all the same non-working symptoms, but if you left it off for a bit it tended to start working again, presumably as it cooled down. However after a while it stopped the "starting working" again and was basically broken.
[Make sure you know how to be safe with mains electronics before you go doing this - there are dangerous voltages inside.]
Opening up the lid was a case of four screws on the underside, but the two at the rear are inaccessible while it's properly mounted on the stand just to make things more difficult.
Anyway, I'd found the power supply board with the big capacitors on it and I'd replaced those because I know that caps are often the thing that go bad in old electronics. Unfortunately, this made no difference (though the piano did briefly start working again just to throw me off the scent). FYI: The big cap in the bottom right of the board was charged to 20v and retained that voltage for at least a couple of days - nice big spark when I shorted it (so use a resistor)!
However, after another session of fiddling and some lucky turning on and off of the piano I worked out that my issue seemed to be that when it was working the machine had 2v or 4v (I think it was AC) measurable at (both sides of) the fuse towards the rear (using the metal heatsink case of that board as ground), and when it wasn't working it had 0v. I traced the track on the underside of the PCB back to one of the end pins of the connector on the RHS of board - this was a wire directly from the big transformer, so I figured either the transformer was broken or... did that solder joint look slightly less than perfect through a magnifying class? Turned out it was! I resoldered all the joints on the bottom of the (what was it, 7 or 8 pin) connector and my Clavinova is working again!
PS Credit to Yamaha for building a piece of kit that lasts this long.
(Other notes: The rectifier near the connector gives out about 20v on the rear-right and the front-left pins. I measure the cap of the (now replaced) big capacitor at the bottom right of the board and it was at 20v while the machine was on. However, the identical big cap next to it (by its "cap") was at 0v - not sure what that's about. Off to the left two of the other 3 or 4 bigger caps were at 8v and 6v and the other two were 0v, I think.)
If you turned it off and on again immediately then you'd get a gentle pop and all the same non-working symptoms, but if you left it off for a bit it tended to start working again, presumably as it cooled down. However after a while it stopped the "starting working" again and was basically broken.
[Make sure you know how to be safe with mains electronics before you go doing this - there are dangerous voltages inside.]
Opening up the lid was a case of four screws on the underside, but the two at the rear are inaccessible while it's properly mounted on the stand just to make things more difficult.
Anyway, I'd found the power supply board with the big capacitors on it and I'd replaced those because I know that caps are often the thing that go bad in old electronics. Unfortunately, this made no difference (though the piano did briefly start working again just to throw me off the scent). FYI: The big cap in the bottom right of the board was charged to 20v and retained that voltage for at least a couple of days - nice big spark when I shorted it (so use a resistor)!
However, after another session of fiddling and some lucky turning on and off of the piano I worked out that my issue seemed to be that when it was working the machine had 2v or 4v (I think it was AC) measurable at (both sides of) the fuse towards the rear (using the metal heatsink case of that board as ground), and when it wasn't working it had 0v. I traced the track on the underside of the PCB back to one of the end pins of the connector on the RHS of board - this was a wire directly from the big transformer, so I figured either the transformer was broken or... did that solder joint look slightly less than perfect through a magnifying class? Turned out it was! I resoldered all the joints on the bottom of the (what was it, 7 or 8 pin) connector and my Clavinova is working again!
PS Credit to Yamaha for building a piece of kit that lasts this long.
(Other notes: The rectifier near the connector gives out about 20v on the rear-right and the front-left pins. I measure the cap of the (now replaced) big capacitor at the bottom right of the board and it was at 20v while the machine was on. However, the identical big cap next to it (by its "cap") was at 0v - not sure what that's about. Off to the left two of the other 3 or 4 bigger caps were at 8v and 6v and the other two were 0v, I think.)
Friday, 26 August 2016
Chrome's task manager doesn't appear when using the Shift+Escape shortcut keys
...but does work when selected from the menu.
There are (or used to be?) problems with some sites like GMail, however Shift + Esc didn't work for me anywhere.
As helpfully suggested by Bruce at https://bugs.chromium.org/p/chromium/issues/detail?id=317276#c15 , if you've got Intel Management and Security stuff on your machine then by default it will have usurped the shortcut. Change it in the Intel settings.
There are (or used to be?) problems with some sites like GMail, however Shift + Esc didn't work for me anywhere.
As helpfully suggested by Bruce at https://bugs.chromium.org/p/chromium/issues/detail?id=317276#c15 , if you've got Intel Management and Security stuff on your machine then by default it will have usurped the shortcut. Change it in the Intel settings.
Tuesday, 26 April 2016
SharePoint 2013 CSOM: Prevent last-modified and last-modified-by (or whatever they're called) from changing when updating programmatically.
Simply doing a
sharePointItem["Editor"] = sharePointItem["Editor"];
sharePointItem["Modified"] = sharePointItem["Modified"];
before the
sharePointItem.Update();
context.ExecuteQuery();
seemed to work for me on a Document Library.
(I tried "Last_x0020_Modified" first which I got from a list of fields somewhere and that gives an error about..."not existing or might be read-only"?)
Also note that there appear to be other "modified"-type fields on a Document Library that might be for search, but I haven't felt the need to understand those.
sharePointItem["Editor"] = sharePointItem["Editor"];
sharePointItem["Modified"] = sharePointItem["Modified"];
before the
sharePointItem.Update();
context.ExecuteQuery();
seemed to work for me on a Document Library.
(I tried "Last_x0020_Modified" first which I got from a list of fields somewhere and that gives an error about..."not existing or might be read-only"?)
Also note that there appear to be other "modified"-type fields on a Document Library that might be for search, but I haven't felt the need to understand those.
Subscribe to:
Posts (Atom)