Paolo Zaboi Administration, Programmazione, Troubleshooting

Applicazioni con pacchetti non installabili o non reinstallabili: come risolvere usando PowerShell

Di recente mi è capitato di dover gestire un problema banale ma curioso, uno di quelli su cui pensi una volta risolto: “ecco questo per il futuro devo davvero ricordarmelo!”. Siccome è una di quelle cose che può essere utile a tutti nella vita di tutti i giorni ho pensato di condividerlo brevemente.

Il Problema:
In breve questo quanto accaduto. Stavo provando ad aggiornare un’applicazione di tipo universal, basata su pacchetti, fatta con Visual Studio di cui ho pubblicato anche una versione sullo store. In passato avevo provato ad installarla anche in locale sul pc di casa che uso per sviluppare. Poi l’avevo rimossa.
Dopo quest’azione mi era diventato impossibile avviare la versione di sviluppo in locale, che per funzionare deve essere distribuita localmente, proprio come fosse stata installata. Questo con errori anomali come l’errore 1104 che, da visual studio, indica che non è stato possibile accedere al percorso di delivery.
Anche da Microsoft Store la versione dell’app pubblicata era diventata impossibile da installare

La Causa
Per ragioni non ben definite l’applicazione in pratica risultava installata da un’utente diverso dal mio, da cui però era diventato impossibile rimuoverla. Forse si trattava di qualche prova fatta in passato con un’utenza non piu’ disponibile.
I due strumenti quindi (Visual Studio e Microsoft Store) non avevano modo di rimuoverla in modo corretto

La Soluzione
La soluzione piu’ rapida per il problema, una volta capito, è stata quella di forzare la rimozione dell’applicazione installata tramite PowerShell, usando utenza e console amministrative. Il comandi Powershell riportati di seguito in pratica consentono di rimuovere il pacchetto indicato per tutti gli utenti.

Procedura

  1. Aprire una console PowerShell con diritti amministrativi
  2. Trovare il nome del pacchetto da rimuovere. Questo lo si puo recuperare in diversi modi:
    • Dal messaggio di errore ricevuto
    • Cercando il suo nome nella cartella %USERPROFILE%\AppData\Local\Packages
      Ad ogni nome cartella corrisponde un pacchetto con lo stesso nome
    • Tramite la query PowerShell
      Get-AppxPackage -AllUsers
  3. Una volta identificato il nome del pacchetto rimuoverlo semplicemente tramite il comando PowerShell
    Get-AppxPackage -Name "[NOMEPACCHETTO]" -AllUsers |Remove-AppxPackage -AllUsers


Paolo Zaboi Monitoring, Performance Tuning, Tecnologia, Troubleshooting

PC Monitoring: una soluzione per un buon Fine Tuning

Con la crescita del Gaming su PC è cresciuta la necessita e la voglia di fare tuning del proprio computer per ottenere migliori prestazioni e assicurarsi una buona durata di tutti i componenti. Questo è dovuto sia alla voglia di ottenere le performance migliori possibili, tenendo bassi i cosi, sia alla voglia di spremere ogni bit possibile dalla nostra soluzione..ma anche alla passione per il tuning che alcuni appassionati di informatica, come me, hanno sempre avuto.

E’ questa passione che porta a voler migliorare sempre e si traduce nel voler avere quel “qualcosa in piu” della semplice ordinaria manutenzione.

Nel caso di un PC, di un Server, o dell’Information Technology in generale questo si traduce in due parole: “Fine Tuning”.

Ma il tuning ha bisogno di misurazioni oggettive per essere ben fatto. Senza strumenti di misura diventa qualcosa di estremamente soggettivo e in qualche modo fatto “a sensazione” che difficilmente raggiunge tutti gli obbiettivi iniziali e spesso porta spese eccessive con risultati ridotti. A volte senza che ce ne si renda onto, non avendo nessun reale riscontro con cui confrontarsi.

Un buon tuning in informatica, come in qualsiasi altra disciplina, parte in primo luogo da una iniziale misurazione oggettiva. Un “assessment” come si dice in gergo… una “valutazione” in cui si prendono delle misurazioni per capire esattamente qual’è la situazione iniziale. Partendo da questa si valutano quindi gli obbiettivi che si vogliono raggiungere e quindi le eventuali spese necessarie. Si fanno i primi interventi, poi si misura ancora. A seguire , se l’obbiettivo non è stato raggiunto, si interviene nuovamente, poi si ri-misura….e cosi via fino al raggiungimento del proprio scopo.

E’ questo l’unico modo di fare Tuning in modo oggettivo: lavorare sui numeri. Altri sistemi non ve ne sono.
Lavorare senza numeri porta purtroppo a modifiche continue, insoddisfazione e interventi dettati dall’emotività che finiscono sempre per lasciare l’amaro in bocca, non avendo un riscontro oggettivo utile a garantire un reale miglioramento e il raggiungimento del risultato.

Partendo da questi presupposti, per il tuning del mio PC da gaming di casa, ho messo insieme una soluzione di monitoring basata su Home Assistant. A questa, gia attiva su un Raspberry Pi, ho aggiunto alcuni elementi tutti presi dal mondo dell’ open source. Vediamoli insieme.

  1. In primo luogo e’ indispensabile un agente da posizionare sul PC per raccogliere tutti i dati di nostro interesse. Nel mio caso si tratta di Open Hardware Monitor. Si tratta di un tool completamente Open Source in grado di raccogliere una serie di metriche dal vostro PC e di mostrarle in tempo reale. La cosa bella, che lo rende interessante al nostro scopo, e’ che e’ in grado di esporre un web server che consente ad una sonda esterna di raccogliere periodicamente le metriche di interesse e di storicizzarle.
  2. A seguire, sul nostro server Home Assistant andremo ad installare una serie di strumenti aggiuntivi. In primo luogo andremo a configurare HA per racogliere dati dal nostro agente OAM (Open Hardware Monitor) indicandogli l’IP a cui questo deve essere raggiunto.
  3. Una volta che la raccolta dati sara’ iniziata, dovremo andare a storicizzare tutti questi valori su un database ottimizzato per le time series (serie di valori continue che producono enormi quantita’ di dati che necessitano di essere salvate con il dispendio minimo possibile di risorse). A questo scopo la mia scelta e’ caduta su InfluxDB, ottimamente integrabile dentro Home Assistant con minimo sforzo.
  4. In ultimo, ma non per importanza, e’ necessario rappresentare questi dati in modo leggibile con uno strumento leggero e capace di lavorare in modo agile con la grossa quantita di dati di monitoraggio che nel tempo che verranno raccolti. Lo strumento ideale, sempre ben integrato in Home Assistant in questo caso è stato Grafana. Anche in questo caso strumento open e ottimizzato ormai da tempo… in grado di gestire quantita’ di dati ben maggiori di quelli che andremo a raccogliere con il nostro monitoraggio domestico.

Una volta configurati questi elementi potremo creare i nostri grafici, utili per tenere sotto controllo le grandezze su cui vorremo andare a lavorare. Nel mio caso si trattera’ in particolare del consumo delle risorse, il consumo di corrente e soprattutto la temperatura di esercizio

Ecco i riferimenti utili da cui partire e qualche guida:

La configurazione di quanto sopra, per inciso, non e’ rapida ed è consigliata ai soli appassionati che abbiano voglia di crearsi una piattaforma domestica per domotica e monitoraggio. Una piattaforma che sara’ poi utile anche per altri fini. Potrete fare grafici della temperatura di casa, dei consumi degli elettrodomestici e di tutti i dati raccoglibile da qualsiasi sensore domestico acquistabile, compatibile con Home Assistant.

Ed ecco un paio di grafici che sono andato a creare che documentano la situazione del mio PC.

In primo luogo la situazione di idle, con solo le attività di sistema in corso dopo l’avvio

…e a seguire una situazione di carico durante una partita di una quarantina di minuti a Spider-Man: Miles Morales (titolo davvero ben fatto che posso solo consigliare…)

Ecco qui quindi tutti i numeri oggettivi su cui fare ragionamenti. Bisogna migliorare il raffreddamento della nuova CPU? Serve veramente altra RAM? La temperatura della GPU e’ stabile? Tutte domande a cui potrete facilmente rispondere guardando i vostri grafici. Poi, una volta fatti i vostri interventi potrete tornare a guardare i grafici per vedere come vanno le cose…. e avanti cosi, cercando sempre di fare meglio!

Con questo penso di avervi dato un’idea ad alto livello della mia soluzione, con tutti i riferimenti per valutarla e pianificarla per le vostre esigenze. Per l’installazione vi rimando alle guide nei link di riferimento riportati nell’articolo. E’ ovviamente una soluzione per esperti che richiede un po’ di dimestichezza con le procedure di installazione riportate e tanta voglia di personalizzare e creare una soluzione che, una volta creata, sarà tutta vostra.

Ma posso dirvi che una volta creata vi darà grandi soddisfazioni grazie alla possibilità di poterla personalizzare a vostro piacimento.

Che dire a questo punto?

Direi: Buon Fine Tuning a tutti!! 🙂

p.s. un grande Grazie all’amico GolemWasHere (al secolo Andre 🙂 ) che mi ha dato tutti gli spunti e le dritte utili per mettere insieme la soluzione

Paolo Zaboi Administration, News, Risoluzione problemi, Troubleshooting

Appunti sulla risoluzione di un blue screen

Alcuni articoli del supporto Ms sono sempre utili e conviene davvero averli pronti sottomano in caso di bisogno. Nel mio caso, come purtroppo a volte accade, il “caso” si è verificato il giorno in cui la mia workstation (Windows 10 pro x64) ha cominciato a bloccarsi in modo completamente inaspettato.

Il blocco si manifestava in modi diversi che sono andati peggiorando con il tempo. In alcuni casi si trattava del completo congelamento dell’interfaccia, senza alcuna attività apparente della macchina. L’unica cosa fattibile era spegnere e riaccendere il pc.

In altri casi invece, diventati via via più frequenti, la macchina si bloccava completamente con la purtroppo famigerata schermata blu contenenti poche informazioni utili al troubleshooting.

I codici di errore riportati non erano oltre tutto costanti e rimbalzavano dal:

IRQ NOT LESS OR EQUAL

al

PAGE FAULT IN NONPAGED AREA

Chi è avvezzo al troubleshooting dei sistemi Windows sa che purtroppo questi due messaggi sono tipici di due macro  tipologie di problemi dietro i quali può essere successo più o meno di tutto: problemi di driver o problemi di memoria.

Da qui quindi è partita la mia indagine.

1) Sono state fatte installazioni/aggiornamenti di recente?

Purtroppo windows 10 fa aggiornamenti in autonomia pertanto la risposta a questa domanda non è così immediata. Per verificarlo comunque è bastato un passaggio su gestione aggiornamenti dove ho verificato che non vi erano stati aggiornamenti particolari oltre alle ultime definizioni di Windows Defender

2) Il sistema riporta errori o problemi inattesi nei log?

Secondo passaggio: verifica in Event viewver. Anche qui nulla di particolare se non degli errori ricorrenti dovuti forse a qualche disinstallazione non andata proprio a buon fine. Questo è forse uno dei punti più “ambigui” dell’analisi in quanto i messaggi potenzialmente preoccupanti possono essere davvero molti. Ho perso molto tempo a risolvere messaggi di errore che nulla avevano a che fare con il mio problema. Male certo non fa… ma è frustrante ritrovarsi a distanza di qualche ora dopo il lavoro di nuovo con lo stesso problema. Unico suggerimento: ignorate gli errori ricorrenti precedenati al problema o, quanto meno, lasciateli in secondo piano e verificateli solo in un secondo momento

3) Il sistema riporta anomalie a livello di periferiche/driver?

Un bel giro in gestione risorse risolve rapidamente questo dubbio. Se nessuna periferica riporta anomalie è comunque consigliabile una verifica della presenza di eventuali driver aggiornati che coprano eventuali bug delle versioni precedenti. Sopratutto se di recente avete aggiunto qualche periferica!

4) Il sistema operativo è integro o riporta anomalie a livello di file, grant, etc… ?

Questo è il punto più difficile da verificare ma Ms ci viene in aiuto con 2 tool: sfc.exe (System File Check utility) e dism.exe (Distributed Image System Maintenance) entrambi disponibili nel sistema operativo. Eccone le descrizioni.

https://support.microsoft.com/it-it/help/947821/fix-windows-update-errors-by-using-the-dism-or-system-update-readiness
https://support.microsoft.com/it-it/help/929833/use-the-system-file-checker-tool-to-repair-missing-or-corrupted-system

Il loro utilizzo, come potete vedere dal contenuto degli articoli, si riassume nel lanciare da un prompth con privilegi elevati i seguenti comandi:

DISM.exe /Online /Cleanup-image /Checkhealth

DISM.exe /Online /Cleanup-image /Restorehealth

sfc /scannow

5) I dischi sono integri?

Questa è un’ipotesi remota ma è comunque meglio verificarla in modo da scartarla a priori. Windows usa come memoria ausiliaria il file di paging che a sua volta è ospitato su uno dei dischi fissi della macchina. Un problema sul disco che ospita questo file potrebbe tradursi in uno degli errori sopra indicati. Ipotesi remota ma lanciare un check dei dischi, in particolare quello di sistema dove c’è il file di paging, male non fa. Possiamo farlo con tramite gli strumenti grafici (pulsante destro sul disco, “Strumenti”, “Controllo disco”) oppure tramite il vetusto ma sempre affidabile chkdsk

chkdsk [volume] /scan

Maggiori dettagli sul comando anche qui potete trovarli sul supporto Ms:

https://technet.microsoft.com/it-it/library/bb491051.aspx

6) Il problema permane? Allora purtroppo potrebbe trattarsi davvero di un problema di RAM hardware…

Per questa verifica Ms ci mette a disposizione un ulteriore too di diagnostica predisposto per lo scopo: MdSched.exe (Strumento Diagnostica Memoria Windows). Il check della memoria per ovvie ragioni può essere verificato solo da tool appositi eseguiti prima dell’avvio del sistema operativo pertanto, con questo strumento, sarà possibile schedulare un checò imediato al prossimo riavvio di windows. Il tool ha diverse modalità di funzionamento (Base,Standard e Advanced) ma la modalità di deafult (Standard) da documentazione risulta già sufficente alla nostra verifica.

Sempre da un promth con privilegi elevati (o tramite la ricerca) lanciamo MdSched.exe

Maggiori dettagli su questo tool li trovate qui:

https://technet.microsoft.com/en-us/library/ff700221.aspx

In ogni caso il check parte automaticamente e basta lasciarlo andare. Se tutto va bene, dopo la conclusione e successivo riavvio, troverete in Event Viewver un messaggio con il risultato del test.

Se invece qualcosa non va il software potrebbe indicarvi un problema su uno dei moduli di memoria oppure addirittura bloccarsi durante il test.

Cosa si fa a quel punto? Come nel mio caso (*sigh*) l’unica cosa che potete fare è togliere i moduli di memoria rilanciando il test fino a quando non riuscirete a capire quale sia il modulo guasto. Consigliabile in particolare fare tentativi di riavvio togliendo prima le memorie di un canale e poi quelle dell’altro. A seguire scambiate i moduli finchè non capite qual’è quello guasto.

Nel mio caso, alla fine dell’analisi, ho salutato con tutti gli onori del caso, un glorioso ma ormai vetusto e difettoso modulo RAM Samsung da 1Gb.

Ma tutto è tornato a funzionare come prima 😉

Paolo Zaboi Administration, SQL Server, SQL Server Toolbox, Troubleshooting

Recover a database with a DAMAGED and/or LOST log file

In this procedure we’ll manage one of the worst situation a DBA has to manage: corrupted files and data loss. When this heppen usually the common way is restoring but we’ll use sql server features to reduce stop time (avoiding a complete restore) and data loss.

Possible starting problems:
Corrupted logfile
Corrupted logfile during a long transaction
Logfile volume corrupted or lost during transactions

At this point there are different solutions following current database settings:

SCENARIO 1: No transactions running during crash.
Solution:
If no transactions were running at crash point the solution is easy.This because SQL server rebuild automatically lost log file during database startup. So:
1) Detach corrupted database
2) Rename the old corrupted logfile in *.OLD
3) Attach database using:

CREATE DATABASE [MYDATABASE] ON
 ( FILENAME = N'D:Microsoft SQL ServerYourDataPathDataDatabase.mdf' )
 FOR ATTACH_REBUILD_LOG
 GO
 Notes:
 - SQL Server will try to rebuild log file in the ORIGINAL path.

SCENARIO 2: Transactions running during crash
Solution:
ATTACH_REBUILD_LOG in this situation *IS NOT* allowed because SQL Server find open transactions in the database and pending rollback/rollforward operations. So you’ll find the following error trying:

“File activation failure. The physical file name “D:Microsoft SQL ServerYourDataPathDataLogfile.ldf” may be incorrect.

The log cannot be rebuilt because there were open transactions/users when the database was shutdown, no checkpoint occurred to the database, or the database was read-only. This error could occur if the transaction log file was manually deleted or lost due to a hardware or environment failure.
Msg 1813, Level 16, State 2, Line 1
Could not open new database ‘MYDATABASE’. CREATE DATABASE is aborted. “

So, follow this procedure:
1) DETACH DATABASE MyDatabase
2) Rename datafile and logfile in MDF.OLD and LDF.OLD
3) Create a new database with THE SAME name and identical original datafile and logfile position. I
4) ALTER DATABASE MyDatabase SET OFFLINE
5) Now you can put the original datafile in the original position
6) ALTER DATABASE MyDatabase SET ONLINE. This will fail but now we’ll can rebuild the log file
7) ALTER DATABASE [MyDatabase ] REBUILD LOG ON (NAME=’MyDatabaseLog’,FILENAME=’D:Microsoft SQL ServerYourDataPathDataLogfile.ldf’)
At this point the database will be usable but SQL Server at the end will show this warning:
Warning: The log for database ‘MyDatabase’ has been rebuilt. Transactional consistency has been lost. The RESTORE chain was broken, and the server no longer has context on the previous log files, so you will need to know what they were. You should run DBCC CHECKDB to validate physical consistency. The database has been put in dbo-only mode. When you are ready to make the database available for use, you will need to reset database options and delete any extra log files.
8) Final Step: open the database to users:
ALTER DATABASE [nomedb] SET MULTI_USER

Notes:
– In recovery model FULL make a new FULL BACKUP as soon as possible because the RESTORE chain is broken and you need a new baseline for log backup.
– *Ask to double-check application consistency* because data recovered could be NOT consistent at application level. (we have done an uncomplete recover). If applicaton checks fails and nothing is fixable rapidly at application levele you have to consider, at the end, only a complete restore.

Paolo Zaboi Administration, SQL Server, SQL Server Toolbox, Troubleshooting

Queries to see rapidly what your SQL Server is doing NOW

1) Blocked And Blocking queries.
If this query returns no rows you have no blocked queries in this moment. Run it more then once to see any few-seconds blocking queries. NOTE: This exclude ONLY problems with long-locking running queries. Cumulative short-term locking contentions need other kinds of debug (see point 2)

SELECT 'BLOCKING STATUS' as Controllo,
BlockedSPID=left(blocked.session_id,5) ,
BlockedQuery=convert(varchar(50),blockedsql.text),
BlockingSPID=convert(varchar(50),blocking.session_id),
BlockingQuery=convert(varchar(50),blockingsql.text)
FROM sys.dm_exec_requests blocked
JOIN sys.dm_exec_requests blocking
ON blocked.blocking_session_id = blocking.session_id
CROSS APPLY
(
SELECT *
FROM sys.dm_exec_sql_text(blocked.sql_handle)
) blockedsql
CROSS APPLY
(
SELECT *
FROM sys.dm_exec_sql_text(blocking.sql_handle)
) blockingsql
GO

2) Time-Wait analysis
SQL Server collects informations about time wait events of your instance for every session. Every event (IO,CPU Processing,Locking and so on) is collected and showed in some dynamic management views from instance start/restart. To see what’s heppening now you can reset one af this views and collect for a short time windows events details for debug purpose. To understand the meaning of every SQL Wait Events see: http://msdn.microsoft.com/it-it/library/ms179984.aspx.
Following you can see a good wait analysis script to cross informations for a fast debug (source: http://www.sqlskills.com/blogs/paul/advanced-performance-troubleshooting-waits-latches-spinlocks/)

DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR); --reset DM view
GO

SELECT
	[owt].[session_id],
	[owt].[exec_context_id],
	[owt].[wait_duration_ms],
	[owt].[wait_type],
	[owt].[blocking_session_id],
	[owt].[resource_description],
	[es].[program_name],
	[est].1,
	[est].[dbid],
	[eqp].[query_plan],
	[es].[cpu_time],
	[es].[memory_usage]
FROM sys.dm_os_waiting_tasks [owt]
INNER JOIN sys.dm_exec_sessions [es] ON
	[owt].[session_id] = [es].[session_id]
INNER JOIN sys.dm_exec_requests [er] ON
	[es].[session_id] = [er].[session_id]
OUTER APPLY sys.dm_exec_sql_text ([er].[sql_handle]) [est]
OUTER APPLY sys.dm_exec_query_plan ([er].[plan_handle]) [eqp]
WHERE [es].[is_user_process] = 1
ORDER BY [owt].[session_id], [owt].[exec_context_id];
GO

3) Open transactions with plan and sql texts
It’s really simple to see informations about current sessions using the old and trusty exec sp_who2 or the dynamic management view sys.dm_exec_requests
But if you need exactly what statements are running and wich plan are they using you need a more complicate query.
This is a good script from http://www.sqlskills.com/blogs/paul/script-open-transactions-with-text-and-plans/ useful to see current transactions with detailed informations about every sessions running.

 SELECT s_tst.[session_id],
   s_es.[login_name] AS [Login Name],
   DB_NAME (s_tdt.database_id) AS [Database],
   s_tdt.[database_transaction_begin_time] AS [Begin Time],
   s_tdt.[database_transaction_log_record_count] AS [Log Records],
   s_tdt.[database_transaction_log_bytes_used] AS [Log Bytes],
   s_tdt.[database_transaction_log_bytes_reserved] AS [Log Rsvd],
   s_est. AS [Last T-SQL Text],
   s_eqp.[query_plan] AS [Last Plan]
FROM sys.dm_tran_database_transactions s_tdt
   JOIN sys.dm_tran_session_transactions s_tst
      ON s_tst.[transaction_id] = s_tdt.[transaction_id]
   JOIN sys.[dm_exec_sessions] s_es
      ON s_es.[session_id] = s_tst.[session_id]
   JOIN sys.dm_exec_connections s_ec
      ON s_ec.[session_id] = s_tst.[session_id]
   LEFT OUTER JOIN sys.dm_exec_requests s_er
      ON s_er.[session_id] = s_tst.[session_id]
   CROSS APPLY sys.dm_exec_sql_text (s_ec.[most_recent_sql_handle]) AS s_est
   OUTER APPLY sys.dm_exec_query_plan (s_er.[plan_handle]) AS s_eqp
ORDER BY [Begin Time] ASC;
GO