PC SOFT

FOROS PROFESIONALES
WINDEVWEBDEV y WINDEV Mobile

Inicio → WINDEV 2025 → DLL WD300WEB64 - RDS - Consommation CPU
DLL WD300WEB64 - RDS - Consommation CPU
Iniciado por Yohann MICHEL, 17,jul. 2025 16:53 - 39 respuestas
Miembro registrado
4 mensajes
Publicado el 17,julio 2025 - 16:53
Bonjour Par ici !

Mon app tourne sur un système en RDS, et j'ai masse de processus lié a la DLL wd300web64 et surtout un parmis les autre qui prends jusqu'a 10% !

C'est apparement lié au champs HTML, et en effet le processus se lance que lorsque que j'ouvre une fenetre avec ce champs a l'intérieur. Mais meme quand je ferme la fenetre, les processus ne se kills pas.

j'ai fait un script qui boucle et qui kill les processus a plus de 7% toutes les 15 minutes sinon mon serveur surcharge !





si jamais quelqu'un a une astuce je prends :)

Merci d'avance !
Miembro registrado
16 mensajes
Publicado el 21,julio 2025 - 15:01
Yohann MICHEL a écrit :
[...]

Bonjour,

Malheureusement pas d'astuce à proposer, mais je rencontre la même problématique chez tous les clients que j'ai mis à jour récemment (à priori update 4 de la version 2025), le processeur est rapidement sollicité à 100 % nécessitant un redémarrage du serveur (les clients étant en RDS).

Pour suivre donc...

Dominique
Publicado el 21,julio 2025 - 15:57
DOMINIQUE FERRAND a écrit :
Yohann MICHEL a écrit :
[...]

Bonjour,

Malheureusement pas d'astuce à proposer, mais je rencontre la même problématique chez tous les clients que j'ai mis à jour récemment (à priori update 4 de la version 2025), le processeur est rapidement sollicité à 100 % nécessitant un redémarrage du serveur (les clients étant en RDS).

Pour suivre donc...

Dominique


Bonjour,
j'ai exactement le même problème. Mais pas nécessairement en RDS. Et pas nécessairement dans tous les cas de champ HTML. Je tente de cerner le problème mais jusqu'à maintenant je n'ai pas trouvé ce qui cause ça spécifiquement.
J'ai écris au support technique dans l'espoir d'une répons, mais je doute que ça aide.
Je continue mes recherches, il y a forcément un pattern puisque le problème n'est pas systématique.
Publicado el 21,julio 2025 - 16:36
Yohann MICHEL a écrit :
Bonjour Par ici !

Mon app tourne sur un système en RDS, et j'ai masse de processus lié a la DLL wd300web64 et surtout un parmis les autre qui prends jusqu'a 10% !

C'est apparement lié au champs HTML, et en effet le processus se lance que lorsque que j'ouvre une fenetre avec ce champs a l'intérieur. Mais meme quand je ferme la fenetre, les processus ne se kills pas.

j'ai fait un script qui boucle et qui kill les processus a plus de 7% toutes les 15 minutes sinon mon serveur surcharge !





si jamais quelqu'un a une astuce je prends :)

Merci d'avance !


Salut,
ok, à force de faire des essais erreurs j'ai trouvé ce qui causait des problèmes dans mon cas.
J'ai une ligne de code qui date de 2014 avec commentaire qui mentionne:
//Il semblerait qu'on éviterait certaines erreurs de type GPF en désactivant le multi-coeur. On verra... -- 2014-10-09
ThreadMode(threadMonoProcesseur)



Dès que je commente la ligne, les champs HTML ne causent plus aucun problème.

En espérant que ça puisse vous aider.

Mathieu
Miembro registrado
16 mensajes
Publicado el 21,julio 2025 - 16:51
Mathieu a écrit :
DOMINIQUE FERRAND a écrit :
Yohann MICHEL a écrit :
[...]
Je continue mes recherches, il y a forcément un pattern puisque le problème n'est pas systématique.



De mon côté, j'ai au moins pu isoler les éléments suivants, y compris sur un "mini projet" :
1 fenêtre, 1 champ de saisie HTML typé saisie d'email, zéro ligne de code.
Je compile en 64 bits et j'exécute en bureau à distance, cette application "vide" charge le processeur de 10 à 30 % en continue jusqu'à fermeture de l'application.
Miembro registrado
15 mensajes
Publicado el 21,julio 2025 - 17:03
Bonjour,

PC Soft semble tarder à poster ma réponse, peut-être parce que je n'étais pas connecté? J'essaie à nouveau.

Après plusieurs essais/erreurs j'ai finalement cerné ce qui causait problème de mon côté.
J'avais cette ligne de code avec commentaire dans mon initialisation de projet.
//Il semblerait qu'on éviterait certaines erreurs de type GPF en désactivant le multi-coeur. On verra... -- 2014-10-09
ThreadMode(threadMonoProcesseur)

Dès que j'ai commenté la ligne, ça s'est remis à fonctionner comme avant. En espérant que ça puisse vous aider.

Bon plus de 10 ans plus tard, je prends la chance de le repasser en multithread :)

J'ai un billet ouvert avec le support : 716 512/456502


Mathieu
Mensaje modificado, 21,julio 2025 - 17:06
Miembro registrado
4 mensajes
Publicado el 21,julio 2025 - 18:19
Perso, Je n'ai pas de ThreadMode dans mon projet.

Et pour le test de dominique, c'est un peu la meme de mon coté,

Mon app ouvre une fenetre avec un champs HTML pour faire un mail. le CPU prends ses 10% et meme a la fermeture de la fenetre, il reste actif a 10%.
Je peux le kill par contre, l'appli reste ok.

Et oui, idem, c'est depuis le dernier update.
Miembro registrado
16 mensajes
Publicado el 22,julio 2025 - 09:37
Yohann MICHEL a écrit :
Perso, Je n'ai pas de ThreadMode dans mon projet.

Et pour le test de dominique, c'est un peu la meme de mon coté,

Mon app ouvre une fenetre avec un champs HTML pour faire un mail. le CPU prends ses 10% et meme a la fermeture de la fenetre, il reste actif a 10%.
Je peux le kill par contre, l'appli reste ok.

Et oui, idem, c'est depuis le dernier update.


@Yohann, en attendant un retour de PC Soft, accepteriez-vous de partager votre script pour killer de façon ciblée les process de wd300web64 ?
Miembro registrado
2.299 mensajes
Publicado el 22,julio 2025 - 11:19
Bonjour,

Avec ExeListeProcessus() et une boucle de ExeTermine() :
https://doc.pcsoft.fr/fr-FR/?3035008&name=exelisteprocessus_fonction
https://doc.pcsoft.fr/?3035004

--
Bon dev,
Jean-Pierre
Miembro registrado
16 mensajes
Publicado el 22,julio 2025 - 12:09
Jean-Pierre BLOCH a écrit :
Bonjour,

Avec ExeListeProcessus() et une boucle de ExeTermine() :
https://doc.pcsoft.fr/fr-FR/?3035008&name=exelisteprocessus_fonction
https://doc.pcsoft.fr/?3035004

--
Bon dev,
Jean-Pierre


Bonjour,

Non, j'ai déjà essayé cette méthode, mais ExeListeProcessus ne donne que les processus de l'utilisateur en cours, or mon besoin est de tuer les process de plus d'une dizaine d'utilisateurs connectés à un serveur et utilisateur de mon application.
Miembro registrado
4 mensajes
Publicado el 22,julio 2025 - 12:16
je l'ai fait en Powershell avec un log complet.

il va kill les processus qui tournent depuis plus de 10 min et qui consomment plus de 10%
J'ai mis ces deux conditions, pour éviter de kill le processus directement (ne sachant pas vraiment son utilité)

Et j'ai programmé ma tache pour qu'elle tourne toutes les 15 min sur ma plage de travail 6h/18h

Si ca peux aider en attendant :)

$processName = "wd300web64exe"  
$maxMinutes = 10
$maxCpuPercent = 7

# Configuration du logging
$logPath = "C:\Logs\ProcessMonitor"
$logFile = "$logPath\ProcessMonitor_$(Get-Date -Format 'yyyy-MM-dd').log"

# Création du dossier de logs s'il n'existe pas
if (-not (Test-Path $logPath)) {
    New-Item -ItemType Directory -Path $logPath -Force | Out-Null
}

# Fonction de logging
function Write-Log {
    param(
        [string]$Message,
        [string]$Level = "INFO"
    )
    $timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    $logEntry = "[$timestamp] [$Level] $Message"
    
    # Écriture dans le fichier de log
    Add-Content -Path $logFile -Value $logEntry -Encoding UTF8
    
    # Affichage console avec couleurs
    switch ($Level) {
        "ERROR" { Write-Host $logEntry -ForegroundColor Red }
        "WARNING" { Write-Host $logEntry -ForegroundColor Yellow }
        "SUCCESS" { Write-Host $logEntry -ForegroundColor Green }
        "KILL" { Write-Host $logEntry -ForegroundColor Magenta }
        default { Write-Host $logEntry -ForegroundColor White }
    }
}

# Début du script
Write-Log "=== DÉBUT DE LA SURVEILLANCE DES PROCESSUS $processName ===" "INFO"
Write-Log "Critères d'arrêt: > $maxMinutes minutes ET > $maxCpuPercent% CPU" "INFO"
Write-Log "Fichier de log: $logFile" "INFO"

try {
    # Recherche des processus
    $processes = Get-Process -Name $processName -ErrorAction SilentlyContinue
    
    if ($processes.Count -eq 0) {
        Write-Log "Aucun processus '$processName' trouvé" "WARNING"
    } else {
        Write-Log "Nombre de processus '$processName' trouvés: $($processes.Count)" "INFO"
        
        $killedCount = 0
        
        $processes | ForEach-Object {
            $process = $_
            $runtime = (Get-Date) - $process.StartTime
            
            Write-Log "Analyse du processus PID: $($process.Id)" "INFO"
            
            try {
                # Mesure CPU simple sur 2 secondes
                $cpu1 = $process.CPU
                Start-Sleep -Seconds 2
                $process.Refresh()
                $cpu2 = $process.CPU
                
                # Calcul du pourcentage CPU instantané
                $cpuUsed = $cpu2 - $cpu1
                $instantCpuPercent = ($cpuUsed / 2) * 100 / $env:NUMBER_OF_PROCESSORS
                
                # Informations du processus
                $processInfo = "PID: $($process.Id) | Durée: $([int]$runtime.TotalMinutes) min | CPU: $([math]::Round($instantCpuPercent,1))% | Mémoire: $([math]::Round($process.WorkingSet/1MB,1)) MB"
                Write-Log $processInfo "INFO"
                
                # Vérification des conditions d'arrêt
                $shouldKill = ($runtime.TotalMinutes -gt $maxMinutes) -and ($instantCpuPercent -gt $maxCpuPercent)
                
                if ($shouldKill) {
                    Write-Log "PROCESSUS CIBLÉ POUR ARRÊT - PID: $($process.Id) (Durée: $([int]$runtime.TotalMinutes) min, CPU: $([math]::Round($instantCpuPercent,1))%)" "KILL"
                    
                    try {
                        Stop-Process -Id $process.Id -Force
                        $killedCount++
                        Write-Log "PROCESSUS ARRÊTÉ AVEC SUCCÈS - PID: $($process.Id)" "SUCCESS"
                    } catch {
                        Write-Log "ERREUR LORS DE L'ARRÊT DU PROCESSUS PID: $($process.Id) - $($_.Exception.Message)" "ERROR"
                    }
                } else {
                    # Diagnostic détaillé
                    if ($runtime.TotalMinutes -gt $maxMinutes) {
                        Write-Log "Processus long mais CPU acceptable - PID: $($process.Id)" "WARNING"
                    } elseif ($instantCpuPercent -gt $maxCpuPercent) {
                        Write-Log "CPU élevé mais durée acceptable - PID: $($process.Id)" "WARNING"
                    } else {
                        Write-Log "Processus normal - PID: $($process.Id)" "INFO"
                    }
                }
                
            } catch {
                Write-Log "ERREUR lors de l'analyse du processus PID: $($process.Id) - $($_.Exception.Message)" "ERROR"
            }
        }
        
        Write-Log "Nombre de processus arrêtés: $killedCount" "INFO"
    }
    
} catch {
    Write-Log "ERREUR GÉNÉRALE DU SCRIPT: $($_.Exception.Message)" "ERROR"
}

# Fin du script
Write-Log "=== FIN DE LA SURVEILLANCE ===" "INFO"
Write-Log "----------------------------------------" "INFO"
Miembro registrado
16 mensajes
Publicado el 22,julio 2025 - 13:43
Wahoo, un grand merci, je vais pouvoir soulager les serveurs de mes clients !
Miembro registrado
15 mensajes
Publicado el 23,julio 2025 - 13:40
Salut,
j'ai reçu une patch du ST.
Comme nous n'avions pas exactement le même problème je ne peux vous dire si ça règle aussi vos situations.
Si vous ne l'avez pas eu demandez le pack d'update associé au billet 716512/456502.
Miembro registrado
16 mensajes
Publicado el 23,julio 2025 - 15:49
Mathieu KURTH a écrit :
Salut,
j'ai reçu une patch du ST.
Comme nous n'avions pas exactement le même problème je ne peux vous dire si ça règle aussi vos situations.
Si vous ne l'avez pas eu demandez le pack d'update associé au billet 716512/456502.


Bonjour,

J'ai également reçu un patch.
Comme indiqué, j'ai mis à jour mon environnement de développement avec le patch, recompilé et livré avec les dll's patchées.
Aucune amélioration de mon côté, les mêmes symptômes (+10 à +30 % de consommation de processeur dès l'ouverture d'une fenêtre avec un champ de saisie HTML, et surtout pas de libération de cette sur consommation à la fermeture de la fenêtre.
Miembro registrado
2.299 mensajes
Publicado el 23,julio 2025 - 18:09
Bonjour,

Quelle est la description (intitulé) du patch chez PC Soft ?

--
Bon dev,
Jean-Pierre
Mensaje modificado, 23,julio 2025 - 18:10
Publicado el 24,julio 2025 - 08:38
Bonjour,

Pour info, s'il y a des développeurs qui utilisent également webdev.
J'ai installé, contraint et forcé (bug du champs html avec la dernière version de chrome), l'update 4 2025 du serveur d'application webdev.
Je constate le même soucis sur le serveur. Le processeur monte dans les tours de façon aléatoire (jusqu'à rendre le site inaccessible).
Le rapport avec cette dll me parait évident...
Miembro registrado
15 mensajes
Publicado el 24,julio 2025 - 13:55
Bonjour,

de mon côté non plus ça n'a pas réglé le problème. Voici ce qu'on m'a répondu lorsque je leur ai fait part de mes conclusions: "J’avais noté une amélioration de la mémoire consommée lors de mes tests. Cela n’est vraisemblablement pas suffisant, je relance l’équipe de développement."
Miembro registrado
16 mensajes
Publicado el 25,julio 2025 - 14:45
Bonjour,
Nouveau correctif reçu hier, 24/07, en fin de journée.
Testé dans la foulée, mais je n'ai pas constaté aucune différence.
Miembro registrado
15 mensajes
Publicado el 25,julio 2025 - 15:43
DOMINIQUE FERRAND a écrit :
Bonjour,
Nouveau correctif reçu hier, 24/07, en fin de journée.
Testé dans la foulée, mais je n'ai pas constaté aucune différence.


Idem de mon côté.
Publicado el 29,julio 2025 - 01:17
Même constat de mon côté : j’observe une consommation CPU anormalement élevée, atteignant jusqu’à 50 % sur certains postes, alors que d'autres ne présentent aucun souci. C’est assez étrange — cela pourrait être lié à certaines mises à jour Windows, mais je n’ai pas encore pu identifier précisément l’origine du problème.

Ce que j’ai pu constater de manière récurrente, c’est que la consommation s’envole dès qu’une fenêtre contenant un champ HTML est ouverte. Et même après fermeture de cette fenêtre, la charge reste anormalement élevée jusqu’à la fermeture complète de l’application.

L’incident a été transmis au support technique et enregistré sous le numéro 716 512.

Pour l’instant, nous sommes complètement bloqués, sans possibilité de retour arrière. Cela soulève de réelles inquiétudes quant au déploiement des futures mises à jour on est en version SaaS, Les evolutions au fil de l'eau presentent des regressions!.

En attendant, nous faisons de notre mieux pour gérer les réclamations clients au cas par cas…

Mathieu KURTH a écrit :
DOMINIQUE FERRAND a écrit :
Bonjour,
Nouveau correctif reçu hier, 24/07, en fin de journée.
Testé dans la foulée, mais je n'ai pas constaté aucune différence.

Idem de mon côté.
Miembro registrado
4 mensajes
Publicado el 04,agosto 2025 - 11:44
Hello,

Des nouvelles par ici pour certains ?
Publicado el 04,agosto 2025 - 16:29
Yohann MICHEL a écrit :
Hello,

Des nouvelles par ici pour certains ?


Bonjour,

J'ai écrit ce matin au support technique, aucune nouvelle pour l'instant.
Je vais remettre la version précédente de notre application, les clients ne
peuvent pas travailler correctement.
Miembro registrado
64 mensajes
Publicado el 05,agosto 2025 - 12:04
Bonjour l'application du patch n'a rien changé également de mon côté.

Je n'ai pas d'autre solution que de ré-installer la 300045g, avec laquelle je n'avais pas de soucis.

C'est très pénible, et le ST en visiblement rien à .....

A suivre.
Miembro registrado
80 mensajes
Publicado el 05,agosto 2025 - 14:55
J'ai également le même problème avec wd300web64.dll qui consomme trop de processeur et sature les serveurs.
Ticket ouvert chez Pc Soft sous la référence : ST/H554453
Miembro registrado
20 mensajes
Publicado el 05,agosto 2025 - 15:11
Bonjour,
Si vous n'avez pas de dépendance en 64bits, avez-vous tenté de générer et tester un exécutable 32bits ?

Bon dev !
Mensaje modificado, 05,agosto 2025 - 15:11
Miembro registrado
3 mensajes
Publicado el 06,agosto 2025 - 17:54
Bonjour

Je suis heureux de voir que je ne suis pas le seul a avoir le problème...
Appli développée depuis fort longtemps, mais depuis quelques temps (j'ai pas cerné depuis quelle mise à jour, mais j'ai l'impression que c'est depuis le passage à 2025 Saas), j'ai pour chaque utilisateurs en RDS, pas mal d'instances de WD300WEB dont certaines qui utilisent fortement le CPU, alors même que l'utilisateur n'est pas sur son poste (logiciel laissé ouvert mais toute fenêtre interne fermée)
et je confirme j'utilise beaucoup le champs HTML dans cette appli...

Ca n'apporte rien en solution, mais si jamais vous trouvez une piste, ou si un patch corrige réellement le problème, je suis preneur aussi :-)

--
Xavier N.
Sympathisant WinDev depuis 1999 !
Publicado el 07,agosto 2025 - 05:40
Yohann MICHEL a écrit :
je l'ai fait en Powershell avec un log complet.

il va kill les processus qui tournent depuis plus de 10 min et qui consomment plus de 10%
J'ai mis ces deux conditions, pour éviter de kill le processus directement (ne sachant pas vraiment son utilité)

Et j'ai programmé ma tache pour qu'elle tourne toutes les 15 min sur ma plage de travail 6h/18h

Si ca peux aider en attendant :)

$processName = "wd300web64exe"  
$maxMinutes = 10
$maxCpuPercent = 7

# Configuration du logging
$logPath = "C:\Logs\ProcessMonitor"
$logFile = "$logPath\ProcessMonitor_$(Get-Date -Format 'yyyy-MM-dd').log"

# Création du dossier de logs s'il n'existe pas
if (-not (Test-Path $logPath)) {
    New-Item -ItemType Directory -Path $logPath -Force | Out-Null
}

# Fonction de logging
function Write-Log {
    param(
        [string]$Message,
        [string]$Level = "INFO"
    )
    $timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    $logEntry = "[$timestamp] [$Level] $Message"
    
    # Écriture dans le fichier de log
    Add-Content -Path $logFile -Value $logEntry -Encoding UTF8
    
    # Affichage console avec couleurs
    switch ($Level) {
        "ERROR" { Write-Host $logEntry -ForegroundColor Red }
        "WARNING" { Write-Host $logEntry -ForegroundColor Yellow }
        "SUCCESS" { Write-Host $logEntry -ForegroundColor Green }
        "KILL" { Write-Host $logEntry -ForegroundColor Magenta }
        default { Write-Host $logEntry -ForegroundColor White }
    }
}

# Début du script
Write-Log "=== DÉBUT DE LA SURVEILLANCE DES PROCESSUS $processName ===" "INFO"
Write-Log "Critères d'arrêt: > $maxMinutes minutes ET > $maxCpuPercent% CPU" "INFO"
Write-Log "Fichier de log: $logFile" "INFO"

try {
    # Recherche des processus
    $processes = Get-Process -Name $processName -ErrorAction SilentlyContinue
    
    if ($processes.Count -eq 0) {
        Write-Log "Aucun processus '$processName' trouvé" "WARNING"
    } else {
        Write-Log "Nombre de processus '$processName' trouvés: $($processes.Count)" "INFO"
        
        $killedCount = 0
        
        $processes | ForEach-Object {
            $process = $_
            $runtime = (Get-Date) - $process.StartTime
            
            Write-Log "Analyse du processus PID: $($process.Id)" "INFO"
            
            try {
                # Mesure CPU simple sur 2 secondes
                $cpu1 = $process.CPU
                Start-Sleep -Seconds 2
                $process.Refresh()
                $cpu2 = $process.CPU
                
                # Calcul du pourcentage CPU instantané
                $cpuUsed = $cpu2 - $cpu1
                $instantCpuPercent = ($cpuUsed / 2) * 100 / $env:NUMBER_OF_PROCESSORS
                
                # Informations du processus
                $processInfo = "PID: $($process.Id) | Durée: $([int]$runtime.TotalMinutes) min | CPU: $([math]::Round($instantCpuPercent,1))% | Mémoire: $([math]::Round($process.WorkingSet/1MB,1)) MB"
                Write-Log $processInfo "INFO"
                
                # Vérification des conditions d'arrêt
                $shouldKill = ($runtime.TotalMinutes -gt $maxMinutes) -and ($instantCpuPercent -gt $maxCpuPercent)
                
                if ($shouldKill) {
                    Write-Log "PROCESSUS CIBLÉ POUR ARRÊT - PID: $($process.Id) (Durée: $([int]$runtime.TotalMinutes) min, CPU: $([math]::Round($instantCpuPercent,1))%)" "KILL"
                    
                    try {
                        Stop-Process -Id $process.Id -Force
                        $killedCount++
                        Write-Log "PROCESSUS ARRÊTÉ AVEC SUCCÈS - PID: $($process.Id)" "SUCCESS"
                    } catch {
                        Write-Log "ERREUR LORS DE L'ARRÊT DU PROCESSUS PID: $($process.Id) - $($_.Exception.Message)" "ERROR"
                    }
                } else {
                    # Diagnostic détaillé
                    if ($runtime.TotalMinutes -gt $maxMinutes) {
                        Write-Log "Processus long mais CPU acceptable - PID: $($process.Id)" "WARNING"
                    } elseif ($instantCpuPercent -gt $maxCpuPercent) {
                        Write-Log "CPU élevé mais durée acceptable - PID: $($process.Id)" "WARNING"
                    } else {
                        Write-Log "Processus normal - PID: $($process.Id)" "INFO"
                    }
                }
                
            } catch {
                Write-Log "ERREUR lors de l'analyse du processus PID: $($process.Id) - $($_.Exception.Message)" "ERROR"
            }
        }
        
        Write-Log "Nombre de processus arrêtés: $killedCount" "INFO"
    }
    
} catch {
    Write-Log "ERREUR GÉNÉRALE DU SCRIPT: $($_.Exception.Message)" "ERROR"
}

# Fin du script
Write-Log "=== FIN DE LA SURVEILLANCE ===" "INFO"
Write-Log "----------------------------------------" "INFO"


Un grand MERCI !
Miembro registrado
80 mensajes
Publicado el 07,agosto 2025 - 11:51
Réponse de Pc Soft que je viens de recevoir et que je vous partage :

Entre les versions 2025 "Update 3" (303040) et "Update 4" (304061) une modification du framework a été faite pour l'appel de CEF afin de limiter la mémoire nécessaire. Cette optimisation provoque une utilisation de CPU excessive sur les configurations qui n'ont pas suffisamment de cœurs et/ou de GPU. Je suis désolé pour le contretemps occasionné.

En attendant le correctif nécessaire pour la version 2025 "Update 4", pour déployer en version 2025 je vous conseille d'installation la version Update 3 et de déployer l'application avec :
https://download.windev.com/fr/download/saas/WINDEVSaaS/2025.awp…
Publicado el 19,agosto 2025 - 10:14
Bonjour à tous,

J'ai trouvé une solution provisoire qui fonctionne aussi bien sur un serveur 2019 que sur le 2022 - 21H2.

J'ai mis l'exécutable de l'application en mode compatibilité "Windows 8", le processeur travaille normalement.

Bonne journée à tous
Miembro registrado
3 mensajes
Publicado el 03,septiembre 2025 - 15:55
Solution provisoire qui ne marche pas de mon coté... au contraire...






--
Xavier N.
Sympathisant WinDev depuis 1999 !
Miembro registrado
2.299 mensajes
Publicado el 03,septiembre 2025 - 16:20
Bonjour,

Il y a un patch :
WD300WEB64.DLL
Concerne WINDEV
Framework WINDEV
Cette mise à jour limite l'occupation du processeur dans les environnements limités en ressources graphiques (absence de GPU, utilisation via bureau distant, RDP / TSE, ...).
https://faq.pcsoft.fr/27138-faq-read.awp
Référence de l'incident : 716512
Disponible depuis le : 02/09/2025
Demander ce Module au ST
S'applique uniquement sur la VI : 304061

--
Bon dev,
Jean-Pierre
Miembro registrado
3 mensajes
Publicado el 03,septiembre 2025 - 18:15
Jean-Pierre BLOCH a écrit :
Bonjour,

Il y a un patch :
WD300WEB64.DLL
Concerne WINDEV
Framework WINDEV
Cette mise à jour limite l'occupation du processeur dans les environnements limités en ressources graphiques (absence de GPU, utilisation via bureau distant, RDP / TSE, ...).
https://faq.pcsoft.fr/27138-faq-read.awp
Référence de l'incident : 716512
Disponible depuis le : 02/09/2025
Demander ce Module au ST
S'applique uniquement sur la VI : 304061

--
Bon dev,
Jean-Pierre


top merci, je vais tester tout de suite !

--
Xavier N.
Sympathisant WinDev depuis 1999 !
Miembro registrado
16 mensajes
Publicado el 04,septiembre 2025 - 10:47
Bonjour,

J'ai testé chez plusieurs clients, et ça fonctionne bien, à condition de bien valoriser la clé de la base de registre à 1 tel que donné dans la faq.

La clé étant dans la branche Current_User, cela nécessite de s'adapter pour que chaque utilisateur concerné ait bien valorisé la clé, d'autant que pc soft m'a invité à ne pas systématiser cette méthode, "à réserver aux environnements limités en ressources graphiques" (bref limiter aux environnements qui posent ce problème de surconsommation de ressources processeur).

Bon dev.
Miembro registrado
189 mensajes
Publicado el 04,septiembre 2025 - 13:07
Oula, ce thread m'inquiète!
Nous sommes encore en 2024 clef. On a pris la 2025 clef, mais on attend comme chaque année le dernier update avant de passer sur celle-ci.
Cette année est 1 peu particulière avec la 2026 qui ne sortira pas en version clef. Ce qui veut dire que si on passe toutes nos applications en 2025 et que la 2025 s'avère instable, nous serons obligés de passer immédiatement à la version SAAS.
Et on hésite à passer à la version SAAS précisément à cause des inévitables régressions qui viendront avec les nouveautés trimestrielles. Vous confirmez mes inquiétudes.
=> grosse hésitation, on vient d'abandonner WM pour les mêmes raisons, mais sortir de WD va demander beaucoup plus d'efforts.
Miembro registrado
1 mensaje
Publicado el 05,septiembre 2025 - 09:19
Bonjour,

Nous sommes sur des serveurs Citrix avec applications publiées et nous avons le même souci. Surcharge des serveurs sur le processus WD300WEB et notre application devient totalement inutilisable. Nous avons demandé le correctif et avons mis à jour les différents fichiers hier soir. Nous croisons les doigts. Nous n'avons pas modifié la clef de registre j'espère donc que ça sera suffisant sans.
Miembro registrado
80 mensajes
Publicado el 05,septiembre 2025 - 20:09
Suite à plusieurs tests avec le correctif "716 512" de PC Soft, il apparaît nécessaire d’intégrer le code d’écriture dans le registre pour maintenir une consommation processeur et mémoire optimale, sans risque de surcharge des machines.

sBrancheRegistre est une chaîne = "HKEY_CURRENT_USER\Software\PC SOFT\wdxxxxweb"
sNomCleRegistre est une chaîne = "FORCE_LOWEND"
SI RegistreLit(registreModeAuto,sBrancheRegistre,sNomCleRegistre)<>1 ALORS
SI (RegistreExiste(sBrancheRegistre) _ou_ RegistreCréeClé(registreModeAuto,sBrancheRegistre)) _et_ pas RegistreEcrit(registreModeAuto,sBrancheRegistre,sNomCleRegistre,1,registreTypeEntier) ALORS
Erreur("Echec de changement de mode des affichages HTML",ErreurInfo())
FIN
FIN
Miembro registrado
14 mensajes
Publicado el 01,noviembre 2025 - 00:54
Bonjour à tous,

J'ai actuellement le problème avec la version 2025 "Update 3" (303040) et justement sur un bureau distant en Remote Desktop Services RDS.

Je n'ai pas encore installé la version 2025 "Update 4" (304061) qui vient d'être proposé dans l'Automatic Update de PCSoft.

J'ai 4 traitements simultanés avec un champ Html utilisant chacun la DLL wd300web64.dll pour automatiser des sites web via du scrapping.
Chaque tache a consommée 35% du CPU. Ma session s'est effondré avec un total d’occupation de 100%.

Je ne sais pas si c'est lié, j'ai un effet de bord qui tombe aléatoirement par la perte de mapping UNC qui sont devenus \\?\\\... dans la fonction fDéplaceFichier

Donc je vais devoir installer la fameuse version 2025 "Update 4" (304061) et applique le patch.
J'aurai aimé avoir une version définitive non ? Style Update 5.

Vos retours sont-ils positifs ?
Miembro registrado
80 mensajes
Publicado el 01,noviembre 2025 - 10:45
La mise à jour Update 5 est disponible.
Je n'ai pas encore osé retiré la clé de registre qui avait été nécessaire avec l'Update 4.

Est-ce que quelqu'un a des retours ?
Miembro registrado
14 mensajes
Publicado el 01,noviembre 2025 - 12:23
Chris a écrit :
La mise à jour Update 5 est disponible.
Je n'ai pas encore osé retiré la clé de registre qui avait été nécessaire avec l'Update 4.

Est-ce que quelqu'un a des retours ?


Merci Chris, pour l'information
Je vois qu'elle date du 30/10/2025 - Update 5 (01A305067)

Et toi ou d'autres, avez vous installé cette mise à jour et constaté une amélioration pour résoudre votre problème ?
Si elle contient bien la solution définitive et sans la manipulation de la clé de registre.

Je sais que c'est tout frais, a suivre dans les semaines à venir et encore merci.
Mensaje modificado, 01,noviembre 2025 - 12:24
Miembro registrado
22 mensajes
Publicado el 18,noviembre 2025 - 09:29
PASCAL ROSAY a écrit :
Chris a écrit :
La mise à jour Update 5 est disponible.
Je n'ai pas encore osé retiré la clé de registre qui avait été nécessaire avec l'Update 4.

Est-ce que quelqu'un a des retours ?

Merci Chris, pour l'information
Je vois qu'elle date du 30/10/2025 - Update 5 (01A305067)

Et toi ou d'autres, avez vous installé cette mise à jour et constaté une amélioration pour résoudre votre problème ?
Si elle contient bien la solution définitive et sans la manipulation de la clé de registre.

Je sais que c'est tout frais, a suivre dans les semaines à venir et encore merci.


Bonjour,

J'ai également le même problème que vous et malgré que je sois en version 305067 (01A30.5.067), le problème d'utilisation du processeur est persistant.

J'ai donc laissé la ligne de code d'écriture dans le registre, MERCI Chris :-)

A suivre

David